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

> On 23 Jun 2014, at 16:31, O. Hartmann <> wrote:
> > Am Sun, 22 Jun 2014 10:10:04 -0700
> > Adrian Chadd <> 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 
-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 
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 
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 
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 
indicated earlier no memory problems with the box).

And by the way, I face several serious issues with the I/O performance on 
days: it takes a long time until portmaster has stepped through the ports which 
about to be updated when CLANG compiler is compiling world/kernel in the 
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

c++ -O2 -pipe -O3 -O3 
-I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I.
-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-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 
DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o
DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o 
InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o
RegisterInfoEmitter.o SetTheory.o SubtargetEmitter.o TGValueTypes.o TableGen.o
X86DisassemblerTables.o X86ModRMFilters.o
-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 
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

Attachment: signature.asc
Description: PGP signature

Reply via email to