Many core dumps in pthread_getspecific.

[Andre Meiser]

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.