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

--Sig_//2Wp9tOd/VRO7Lm8ANz/.9H
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Tue, 01 Jul 2014 17:23:14 +0200
Willem Jan Withagen <[e-mail]> schrieb:

> On 2014-07-01 16:48, Rang, Anton wrote:
> > DOT =3D> DOD
> >
> > 444F54 =3D> 444F44
> >
> > That's a single-bit flip.  Bad memory, perhaps?
>=20
> Very likely, especially if the system does not have ECC....
> It just happens on rare occasions that a alpha particle, power cycle, or=
=20
> any things else disruptive damages a memory cell. And it could be that=20
> it requires a special pattern of accesses to actually exhibit the error.
>=20
> In the past (199x's) 'make buildworld' used to be a rather good memory=20
> tester. But nowadays look at
> 	http://www.memtest.org/
>=20
> This tool has found all of the bad memory in all the systems I used and=20
> or build for others...
> Note that it might take a few runs and some more heat to actually=20
> trigger the faulty cell, but memtest86 will usually find it.
>=20
> Note that on big systems with lots of memory it can take a loooooong=20
> time to run just one full testset to completion.
>=20
> --WjW

I already testet via memtest86+ (had to download the linux image, the port =
on FreeBSD is
broken on CURRENT). It didn't find anything strange so far.

I will do another test.

I realised, that on that that specific box, the chipset temperature is 81 G=
rad Celius.
The chipset is a Eaglelake P45 - in which the memory controller resides on =
that old
platform. dmidecode gives:

        Manufacturer: ASUSTeK Computer INC.
        Product Name: P5Q-WS
        Version: Rev 1.xx

>=20
>=20
> >
> > Anton
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-freebsd-current@f=
reebsd.org] On
> > Behalf Of O. Hartmann Sent: Tuesday, July 01, 2014 8:08 AM
> > To: Dimitry Andric
> > Cc: Adrian Chadd; FreeBSD CURRENT
> > Subject: Re: [CURRENT]: weird memory/linker problem?
> >
> > Am Mon, 23 Jun 2014 17:22:25 +0200
> > Dimitry Andric <[e-mail]> schrieb:
> >
> >> On 23 Jun 2014, at 16:31, O. Hartmann <[e-mail]> wr=
ote:
> >>> Am Sun, 22 Jun 2014 10:10:04 -0700
> >>> Adrian Chadd <[e-mail]> schrieb:
> >>>> When they segfault, where do they segfault?
> >> ...
> >>> 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!
> >>
> >> I think what Adrian meant was: can you run svn (or another crashing
> >> program) in gdb, and post a backtrace?  Or maybe run ktrace, and see
> >> where it dies?
> >>
> >> Alternatively, put a core dump and the executable (with debug info) in
> >> a tarball, and upload it somewhere, so somebody else can analyze it.
> >>
> >> -Dimitry
> >>
> >
> > It's me again, with the same weird story.
> >
> > After a couple of days silence, the mysterious entity in my computer is=
 back. This
> > time it is again a weird compiler message of failure (trying to buildwo=
rld):
> >
> > [...]
> > c++  -O2 -pipe -O3 -O3
> > c++ -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/i=
nclude
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -=
I.
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/cla=
ng/include
> > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTAN=
T_MACROS
> > -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-fr=
eebsd11.0\"
> > -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=
=3D\"\"
> > -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++=
11
> > -fno-exceptions -fno-rtti -Wno-c++11-extensions
> > -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/=
Host.cpp -o
> > Host.o --- GraphWriter.o --- In file included
> > from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Suppor=
t/GraphWriter.cpp:14: /usr/src/lib/clang/libllvmsupport/../../../contrib/ll=
vm/include/llvm/Support/GraphWriter.h:269:10:
> > error: use of undeclared identifier 'DOD'; did you mean 'DOT'? O <<
> > DOD::EscapeString(Label); ^~~
> > DOT /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llv=
m/Support/GraphWriter.h:35:11:
> > note: 'DOT' declared here namespace DOT {  // Private functions... ^ 1 =
error
> > generated. *** [GraphWriter.o] Error code 1
> >
> >
> > Well, in the past I saw many of those messages, especially not found la=
bels of
> > routines in shared objects/libraries or even those "funny" misspelled m=
essages shown
> > above.
> >
> > I can not reproduce them after a reboot, but as long as the system is r=
unning with
> > this error occured, it is sticky. So in order to compile the OS success=
fully, I
> > reboot.
> >
> > Does anyone have an idea what this could be? Since it affects at the mo=
ment only one
> > machine (the other CoreDuo has been retired in the meanwhile), it feels=
 a bit like a
> > miscompilation on a certain type of CPU.
> >
> > Thanks for your patience,
> >
> > Oliver
> > _______________________________________________
> > [e-mail] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o=
rg"
> >



--Sig_//2Wp9tOd/VRO7Lm8ANz/.9H
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

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

iQEcBAEBAgAGBQJTstTUAAoJEOgBcD7A/5N89rQH/1933pGeEp+PDArV3ojerZA+
nbhR9KuN8m286s7WJc3XMZHxdnYaS8y24mAJW0EWIEu4RbjWT5vAlGk8Oyd9p8XB
JGrUMN5zIcnJsxiCCZTL78ApNfivreP9i9GBIYlLdvaP+uBKE2gE44Q83bJYqoLB
2LUN2nb6ndOzINGwBQ+ndnKrLLzh/k8C/NO2qvGgxZlI5Ur/GgF5yKnltMN06Hrc
hCyKrXJsDo1ADtl0AE4ADnG/KD3Qg55xoTxQKjWvN2MovGs6G1XKaki0fPQrA0UZ
kjL5Ye/qRuEYrUIgadEWMNkGHGWMgyVSNFot0CLrfED8ogMdm1XmrH+bcf/OOY0=
=1Fe3
-----END PGP SIGNATURE-----

--Sig_//2Wp9tOd/VRO7Lm8ANz/.9H--