bug#25178: 26.0.50; Crash when pressing C-g in TTY mode

[Eli Zaretskii <eliz@gnu.org>]

> 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?