Re: [CURRENT]: weird memory/linker problem?

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

> When they segfault, where do they segfault?
> 
> 
> 
> -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 ports tree update
is performed via using /usr/bin/svn. Now, ~ three hours of regular work (KDevelop, some
GIMP, LaTeX work, nothing special, but a bit memory consuming regrading GIMP) 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, the memory map
or something else) or is it in fact the agony of my computer system? As reported 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 to check
whether RAM, the CPU itself and, as an additional possibility, the disk i/o controller
(Intel ICH10)?

Thanks for your patience,

Oliver
 
> 
> 
> On 22 June 2014 07:56, O. Hartmann <ohartman_at_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 it is
> > impossible to start certain applications, like Firefox - they segfault. More
> > disturbing is the fail of the linker when building world. Sometimes I get strange
> > messages like
> >
> > relocation truncated to fit: R_X86_64_PC32 against symbol `__error' defined 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 checked 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 two core,
> > another Q6600 quadcore, both systems have 8 GB RAM). This phenomenon also occured two
> > or three months ago on another machine with 32 GB RAM and a Core-i7 3930K, 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 although 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 right. 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 everything was all
> > right again.
> >
> > Those errors are frequent on 8GB, C2D based systems and at the moment not present any
> > more on more modern systems with more memory as described above. This could be a
> > coincidence, but it is strange anyway.
> >
> > I do not exclude dying hardware, but I'd like to ask whether there is something
> > strange going on with FreeBSD's memory management at the moment and whether 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 behaviour 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 these 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 pass the
> > portmaster -da, which is quick when not compiling world. On another system on
> > which /usr/ports is residing on ZFS (the box has 16GB RAM!), it takes sometimes 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 updating 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 exact log of the
> > problems, but I think if there is an issue not with the hardware, I report those in.
> >
> > Regards,
> >
> > oh