Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jun 2014 16:31:15 +0200
From:      "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: [CURRENT]: weird memory/linker problem?
Message-ID:  <20140623163115.03bdd675.ohartman@zedat.fu-berlin.de>
In-Reply-To: <CAJ-Vmok0Oh6XGe62acXE-82pTmEaouibd1GqDT0pCo8P6x6Hog@mail.gmail.com>
References:  <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> <CAJ-Vmok0Oh6XGe62acXE-82pTmEaouibd1GqDT0pCo8P6x6Hog@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/IpG6eT_ItLKPYOE6nw4KEeP
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Sun, 22 Jun 2014 10:10:04 -0700
Adrian Chadd <adrian@freebsd.org> schrieb:

> When they segfault, where do they segfault?
>=20
>=20
>=20
> -a

Now I get more fun.

After a buildworld and reboot, the box in question is at CURRENT:

FreeBSD 11.0-CURRENT #0 r267782: Mon Jun 23 13:12:56 CEST 2014 amd64

After a reboot, everything is/was all right. After reboot, I did an update =
of the ports
tree (I do this regularily). I configured /etc/make.conf that way, that por=
ts tree update
is performed via using /usr/bin/svn. Now, ~ three hours of regular work (KD=
evelop, some
GIMP, LaTeX work, nothing special, but a bit memory consuming regrading GIM=
P) I tried
updating the ports tree and surprisingly the tree is left over in a unclean=
 condition
while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited on =
signal 11
(core dumped)).

Using /usr/local/bin/svn, which is from the devel/subversion port, performs=
 well, while
FreeBSD 11's svn contribution dies as described. It did not hours ago!

Well, this drives me nuts. Is it a bug in FreeBSD (maybe relocating libs, t=
he memory map
or something else) or is it in fact the agony of my computer system? As rep=
orted below,
memory checks via memtest didn't show up any kind of faulty memory.

I'm out of ideas. Is there a way to stress test the CPU and memory system t=
o check
whether RAM, the CPU itself and, as an additional possibility, the disk i/o=
 controller
(Intel ICH10)?

Thanks for your patience,

Oliver
=20
>=20
>=20
> On 22 June 2014 07:56, O. Hartmann <ohartman@zedat.fu-berlin.de> wrote:
> >
> > Hello.
> >
> > I face a strange problem on a set of CURRENT driven boxes. The systems =
in question are
> > all the same version of CURRENT (more or less, a week or so discrepancy=
).
> >
> > The boxes affected have 8 GB of RAM and are old-style Core2Duo systems.
> >
> > The phenomenon:
> >
> > Starting up the box shows the operating system working. But sometimes i=
t is
> > impossible to start certain applications, like Firefox - they segfault.=
 More
> > disturbing is the fail of the linker when building world. Sometimes I g=
et strange
> > messages like
> >
> > relocation truncated to fit: R_X86_64_PC32 against symbol `__error' def=
ined in .text
> >
> > when compiling/linking. The funny thing is: rebooting the box and doing=
 exactly the
> > same very often leaves the system then operable - starting applications=
 works,
> > compiling works!
> >
> > First I thought this could be a indication of a dying system and so I c=
hecked the
> > memory for two days non-stop without any indication of anything wrong. =
The boxes do
> > not have ECC RAM - it's Intel.
> >
> > I see this problem on two C2D based boxes relatively often (one E8400 t=
wo core,
> > another Q6600 quadcore, both systems have 8 GB RAM). This phenomenon al=
so occured two
> > or three months ago on another machine with 32 GB RAM and a Core-i7 393=
0K, but it
> > went away (it was the very same error as shown above).
> >
> > Another system, a i3-3220 with 16 GB RAM never showed the problem altho=
ugh that system
> > build world also on a regular basis very frequent as the C2D systems do.
> >
> > Well, I feel a bit confused. On the first view, the problem looks weird=
 and it
> > indicates a kind of memory problem - but testing the memory didn't show=
 anything
> > wrong.
> >
> > Today "windowmaker" stopped starting due to a malformed command in one =
of
> > windowmaker's library. I did reboot the box and everything was all righ=
t. Then, also
> > today, I tried compiling world and I got a weird error message about a =
misspelled
> > "Int__xxx", I can not remember exactly the text, I rebooted and everyth=
ing was all
> > right again.
> >
> > Those errors are frequent on 8GB, C2D based systems and at the moment n=
ot present any
> > more on more modern systems with more memory as described above. This c=
ould be a
> > coincidence, but it is strange anyway.
> >
> > I do not exclude dying hardware, but I'd like to ask whether there is s=
omething
> > strange going on with FreeBSD's memory management at the moment and whe=
ther those
> > problems could also be triggered by some nasty bug? I never see a crash=
 (which would
> > also indicated faulty hardware), I mostly realise those strange behavio=
ur either
> > after a fresh boot or after I ran some memory disk i/o intensive jobs, =
like updating
> > the ports tree.
> >
> > By the way, FreeBSD CURRENT suffer from a tremendous performance cut th=
ese days when
> > compiling world and updating the ports tree and running portmaster. On =
one box, on
> > which ports reside on a UFS partion, it takes more than 8 minutes to pa=
ss the
> > portmaster -da, which is quick when not compiling world. On another sys=
tem on
> > which /usr/ports is residing on ZFS (the box has 16GB RAM!), it takes s=
ometimes 30(!)
> > minutes to perform a "svn update" while compiling world (that is the i3=
-3220 with 16
> > GB RAM system), it takes 6 - 15 minutes when the box is relaxed and upd=
ating the
> > ports tree the first time (every subsequent update is much faster).
> >
> > Well, I know these reports of mine are a bit weird since I have no exac=
t log of the
> > problems, but I think if there is an issue not with the hardware, I rep=
ort those in.
> >
> > Regards,
> >
> > oh



--Sig_/IpG6eT_ItLKPYOE6nw4KEeP
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJTqDo3AAoJEOgBcD7A/5N8mEQH/1sMKV3nY1Xd4VI7gVIOZdQE
OmHXAAq426AKLebrsjk+lx69wevM95PoWRAwK9LkR4oJy34rGpgZu45KrcDEq+j7
yx0YlcG14gjeFPVmy+N/KqBp8qFNUVrt67dBRV0nkL/hQ+ipc6Kndp9oO6S6lxE6
Wzdc3EocWs13YPs9LScDEbu6J4+QXZ4pZ9LdgyCt2UbOJdFM21/oiNJDw0hjVLmM
qsGfXG+1IdX4Nwwkf4f2QA/Giyd8d48ULL29XOGuN4e/f6P8YZbDMOWMkBS2LMDZ
PDQQ1EX4bxrrBIcP2GMNcZIGVWcLTtHpsmJlJbd0fTV36K9ORx+Ty3CoZS9MEpY=
=KMWY
-----END PGP SIGNATURE-----

--Sig_/IpG6eT_ItLKPYOE6nw4KEeP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140623163115.03bdd675.ohartman>