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

Am Mon, 23 Jun 2014 17:22:25 +0200
Dimitry Andric <dim_at_FreeBSD.org> schrieb:

> On 23 Jun 2014, at 16:31, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote:
> > Am Sun, 22 Jun 2014 10:10:04 -0700
> > Adrian Chadd <adrian_at_freebsd.org> 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
> 

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 error (SIG 10).
Rebooting solved the problem. I didn't recompile the system or any client with DEBUG
flags set on so far. So, sorry, this issue is still open, but it is not even 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 somehow 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 memory 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 CURRENT these
days: it takes a long time until portmaster has stepped through the ports which are
about to be updated when CLANG compiler is compiling world/kernel in the background.
This phenomenon has grown worse since earlier this year (~ February). 

Source at revision 267867. FreeBSD 11.0-CURRENT #0 r267816: Tue Jun 24 14:02: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/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++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 CodeGenInstruction.o
CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o
DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o
DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o
InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o
RegisterInfoEmitter.o SetTheory.o SubtargetEmitter.o TGValueTypes.o TableGen.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 `imemalign':
jemalloc_jemalloc.c:(.text+0x2605): relocation truncated to fit: R_X86_64_PC32 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