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

--Sig_/swp/xr4CKvrO0JYyfGdywK3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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]> wrote:
> > 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 unc=
lean condition
> > while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited=
 on signal 11
> > (core dumped)).
> >=20
> > Using /usr/local/bin/svn, which is from the devel/subversion port, perf=
orms well,
> > while FreeBSD 11's svn contribution dies as described. It did not hours=
 ago!
>=20
> 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?
>=20
> Alternatively, put a core dump and the executable (with debug info) in a
> tarball, and upload it somewhere, so somebody else can analyze it.
>=20
> -Dimitry
>=20

Here I am again.

So far, a report what I did. Regarding to the svn issue, I tried to
recompile " make -C usr.bin/svn clean depend obj all install" with setting =
"-O0 -g
-DDEBUG" in /etc/make.conf and /etc/src.conf (disabling all the -O flags I =
use
usually). gdb complained about missing symbols. After the recompilation the=
 onboard "svn"
didn't crash  anymore and the strange story seems to continue.

Firefox, so far, also crashed yesterday - out of the blue - with a bus erro=
r (SIG 10).
Rebooting solved the problem. I didn't recompile the system or any client w=
ith DEBUG
flags set on so far. So, sorry, this issue is still open, but it is not eve=
n less weird.


Next, today, I tried recompiling world. The build process fails on the box =
in question
with "my well known friend" relocation truncated to
fit: R_X86_64_PC32 against symbol error. See below.

I'm about to reboot the box and restart building world without having prior=
 to the build
started any memory consuming applications.

Since the problems seem to be "randomly" I ask myself whether this is someh=
ow related to
the ASLR stuff mentioned earlier in the list. I also will disable -O3 again=
 with the
next build to ensure that CLANG isn't miscompilating something.

As mentioned in the list before, I tried to find some CPU-burning and memor=
y eating
applications/tests, but since math/mprime is i386 only and sysutils/cpuburn=
 only covers
"ancient" CPUs, I feel a bit lost in that task and leftover with memtest86 =
(which
indicated earlier no memory problems with the box).

And by the way, I face several serious issues with the I/O performance on C=
URRENT these
days: it takes a long time until portmaster has stepped through the ports w=
hich are
about to be updated when CLANG compiler is compiling world/kernel in the ba=
ckground.
This phenomenon has grown worse since earlier this year (~ February).=20

Source at revision 267867. FreeBSD 11.0-CURRENT #0 r267816: Tue Jun 24 14:0=
2:22 CEST 2014
amd64.

[...]
c++ -O2 -pipe -O3 -O3 -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm=
/include
-I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include
-I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I.
-I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/inclu=
de
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MA=
CROS
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebs=
d11.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  -static -L/usr/obj/usr/src/tmp/legacy/usr/=
lib -o tblgen
AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o CTagsEmitter.o
CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstructi=
on.o
CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGI=
SelEmitter.o
DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcher=
Opt.o
DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDeco=
derEmitter.o
InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmit=
ter.o
RegisterInfoEmitter.o SetTheory.o SubtargetEmitter.o TGValueTypes.o TableGe=
n.o
X86DisassemblerTables.o X86ModRMFilters.o
X86RecognizableInstr.o /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/..=
/../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/obj/usr/src/tmp/usr=
/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a
-lncurses -legacy /usr/lib/libc.a(jemalloc_jemalloc.o): In function `imemal=
ign':
jemalloc_jemalloc.c:(.text+0x2605): relocation truncated to fit: R_X86_64_P=
C32 against
symbol `__je_arena_malloc_large' defined in .text section
in /usr/lib/libc.a(jemalloc_arena.o) c++: error: linker command failed with=
 exit code 1
(use -v to see invocation) *** [tblgen] Error code 1

make[3]: stopped in /usr/src/usr.bin/clang/tblgen


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

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

iQEcBAEBAgAGBQJTqsvUAAoJEOgBcD7A/5N8MZ8H/0Ch250rZm0IFEr9x9YAoLqS
Tv2mOVaeXNVR/F7cIqYRVWivv0Z378G0kwHk3nmVXeptOfNzl7Z51GpT1xEGF9Um
W9m6peo67QdxgXOiuV5Q3Vj0wJ2plVZ6vddxUNzFYKHmJednJ6+/yJn6a+eDuYL0
q8SKxG6tOFYVQ8R2zldTpYr1Q3nyssmGtqLru6Y2Kp51n32GW0kymaxYi1q7CR3E
m1P+ds3swBhQgt3OFp6ERKsINQBCC9TokOxiqq3iRk08Vg4DHbM2yUTc/r1a2LJQ
c5e1O/ErA4ydie5YYGGObqinT+ubPYlOlrF8gjxRbkdYrKseU5BmyC2fzR1PHtU=
=dlPP
-----END PGP SIGNATURE-----

--Sig_/swp/xr4CKvrO0JYyfGdywK3--