On Wed, Jun 03, 2015 at 16:58 +0200, Konstantin Belousov wrote:
> You should recompile both libc and libthr with debugging symbols, like
> cd /usr/src
> (cd lib/libc && make all install DEBUG_FLAGS=-g)
> (cd lib/libthr && make all install DEBUG_FLAGS=-g)
> then obtain the core dump and post backtraces.

Thank you, that was exactly what I was looking for. Now I like FreeBSD even 
more. ;)

I made this short after and also rebooted the entire system to make all 
programmes use those debug libs. Since than I had not a single core dump.

I experienced something similar in the past, that with activated debugging some 
errors can't be triggered any longer.

At the moment I'm happy without crashes and I can work with this system. As 
soon as I'm getting a new core dump, I'll post the backtrace. If this won't 
happen for weeks, I may recompile the libs again, try to find a way to trigger 
the bug on purpose, enable the debug flag again and than provide the info.

In the meantime, maybe a core developer may think about the lines of code I'd 
provided. Why is _get_curthread() compared to NULL at thr_kern.c (line 601) but 
not at thr_spec.c (line 224)? Either _get_curthread() never ever returns NULL, 
than it's pointless to test it or it's missing [not only] at thr_spec.c.

I'm using activated hyperthreading:

% sysctl hw.model hw.machine hw.ncpu
hw.model: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
hw.machine: amd64
hw.ncpu: 8

Sincerely yours Andre.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to