Re: mesalib abort

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Thu, 17 Sep 2020 12:04:10 +0100
Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:

> When running glmark2 with native xsrc on -current/amd64, I get
> 
> Program terminated with signal SIGABRT, Aborted.
> #0  0x00007f7ff5844a2a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
> (gdb) bt
> #0  0x00007f7ff5844a2a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
> #1  0x00007f7ff160a461 in pthread_sigmask (how=<optimized out>, 
>     set=<optimized out>, oset=<optimized out>)
>     at /usr/src/lib/libpthread/pthread_misc.c:164
> #2  0x00007f7fed75fec3 in u_thread_create (
>     routine=0x7f7fed75ff06 <util_queue_thread_func>, param=0x7f7ff7e9f220)
>     at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:50
> #3  util_queue_create_thread (queue=queue@entry=0x7f7ff7e8b900, 
>     index=index@entry=0)
>     at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:350
> #4  0x00007f7fed7604ad in util_queue_init (queue=queue@entry=0x7f7ff7e8b900, 
>     name=name@entry=0x7f7fef727c8b "disk$", max_jobs=max_jobs@entry=32, 
>     num_threads=num_threads@entry=1, flags=flags@entry=7)
>     at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:466
> ...
> 
> /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:50:
>     41     thrd_t thread;
>     42  #ifdef HAVE_PTHREAD
>     43     sigset_t saved_set, new_set;
>     44     int ret;
>     45  
>     46     sigfillset(&new_set);
>     47     sigdelset(&new_set, SIGSYS);
>     48     pthread_sigmask(SIG_BLOCK, &new_set, &saved_set);
>     49     ret = thrd_create( &thread, routine, param );
>     50     pthread_sigmask(SIG_SETMASK, &saved_set, NULL);
>     51  #else
>     52     int ret;
>     53     ret = thrd_create( &thread, routine, param );
>     54  #endif
>     55     if (ret)
>     56        return 0;
>     57  
>     58     return thread;
> 
> 
> It looks as though line 50 simply undoes line 48, and it doesn't matter
> whether or not line 49 fails. How can this break?

This is a red herring. Because they mask the SIGSEGV/SIGBUS handlers
you are not getting the actual fault location which happens inside
thrd_create. Instead the process takes the fault when the signal mask
is restored. This code is severly broken and upstream should fix it.
Anyway, If you comment out the signal masking crap you will get a
proper backtrace.

-Tobias