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"
