Eli Zaretskii <eliz@gnu.org> writes:

> > From: Elias Martenson <elias.martenson@murex.com>
> > CC: <25178@debbugs.gnu.org>
> > Date: Tue, 13 Dec 2016 11:07:08 +0800
> > 
> > Here is the actual stack trace from the core dump generated during the
> > crash:
> > 
> >     Machine ID: 50467f3a69eb4dbea19c8a2972949839
> >       Hostname: em-desktop
> >        Storage: /var/lib/systemd/coredump/core.emacs.50067.45a62f2ad9804a0b81fed25ad8faffab.21460.1481598260000000000000.lz4
> >        Message: Process 21460 (emacs) of user 50067 dumped core.
> >                 
> >                 Stack trace of thread 21460:
> >                 #0  0x00007fec16127f5f raise (libpthread.so.0)
> >                 #1  0x0000000000553c66 terminate_due_to_signal (emacs-26.0.50)
> >                 #2  0x00000000005783c1 handle_fatal_signal (emacs-26.0.50)
> >                 #3  0x0000000000578392 deliver_thread_signal (emacs-26.0.50)
> >                 #4  0x00000000005783f8 deliver_fatal_thread_signal (emacs-26.0.50)
> >                 #5  0x00000000005785ae handle_sigsegv (emacs-26.0.50)
> >                 #6  0x00007fec16128080 __restore_rt (libpthread.so.0)
> >                 #7  0x00007fec161296a0 __lll_unlock_elision (libpthread.so.0)
> >                 #8  0x0000000000677a94 sys_mutex_unlock (emacs-26.0.50)
> >                 #9  0x000000000067638d release_global_lock (emacs-26.0.50)
> >                 #10 0x0000000000676d75 really_call_select (emacs-26.0.50)
> >                 #11 0x00000000005d4a02 flush_stack_call_func (emacs-26.0.50)
> >                 #12 0x0000000000676e2b thread_select (emacs-26.0.50)
> >                 #13 0x0000000000651168 wait_reading_process_output (emacs-26.0.50)
> >                 #14 0x00000000004252be sit_for (emacs-26.0.50)
> >                 #15 0x000000000055bc48 read_char (emacs-26.0.50)
> 
> Hmm...  Is calling pthread_mutex_unlock twice in a row, without an
> intervening call to pthread_mutex_lock, supposed to segfault?  Posix
> seems to say the result is undefined behavior, but AFAICT by looking
> in the glibc sources, its implementation triggers a crash in that
> case.
> 
> Strangely, I don't see this on the GNU/Linux system to which I have
> access, although Emacs definitely calls pthread_mutex_unlock twice in
> a row in the scenario of this bug report.  Is this some change in
> latest versions of glibc?

Calling pthread_mutex_unlock() twice has to be undefined behaviour. In
fact, it can never work. Imagine what would happen if a different thread
called pthread_mutex_lock() on the mutex between two the two unlock
calls. In that case, you'd be unlocking a mutex help by a different
thread which is obviously very dangerous.

Regards,
Elias