From owner-freebsd-current@FreeBSD.ORG Mon Jun 23 14:31:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26C34985; Mon, 23 Jun 2014 14:31:23 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF3FB2E71; Mon, 23 Jun 2014 14:31:22 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Wz5HE-001LKx-5T>; Mon, 23 Jun 2014 16:31:20 +0200 Received: from g225054098.adsl.alicedsl.de ([92.225.54.98] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Wz5HE-002MTP-0f>; Mon, 23 Jun 2014 16:31:20 +0200 Date: Mon, 23 Jun 2014 16:31:15 +0200 From: "O. Hartmann" To: Adrian Chadd Subject: Re: [CURRENT]: weird memory/linker problem? Message-ID: <20140623163115.03bdd675.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/IpG6eT_ItLKPYOE6nw4KEeP"; protocol="application/pgp-signature" X-Originating-IP: 92.225.54.98 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:31:23 -0000 --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 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 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--