Many core dumps in pthread_getspecific.

[Konstantin Belousov]

On Wed, Jun 03, 2015 at 01:34:04PM +0200, Andre Meiser wrote:
> Hi,
> 
> I'm new to FreeBSD and I'm running into a lot of core dumps (mainly from Xorg, but also from vim, firefox, ...).
> That's why I asked on freebsd-questions:
> 
> https://lists.freebsd.org/pipermail/freebsd-questions/2015-June/266138.html
> https://lists.freebsd.org/pipermail/freebsd-questions/2015-June/266141.html
> 
> The last Xorg crash was less than 2h ago. :(
> 
> It looks like that there is a missing check for NULL in lib/libkse/thread/thr_spec.c (line 211-214):
> 
>     pthread = _get_curthread();
> 
>     /* Check if there is specific data: */
>     if (pthread->specific != NULL && (unsigned int)key < PTHREAD_KEYS_MAX) {
> 
> If pthread is NULL it will core dump. So maybe something like this would help:
> 
>     if (pthread != NULL && pthread->specific != NULL && (unsigned int)key < PTHREAD_KEYS_MAX) {
> 
> But as I'm said, I'm new to FreeBSD I can't evaluate it yet.
> 
> I'm running the most recent stable:
> 
> % uname -a
> FreeBSD andre 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015
> 
> I haven't compiled the base system so far. Maybe a more experienced FreeBSD guy can verify this and decide if it makes any sense or if I have to dig any deeper into it.

The backtraces you posted do not make any sense, e.g. pthread_mutex_unlock()
does not call pthread_getspecific(), and pthread_getspecific() is not
recursive.

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.