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

[Elias Martenson <elias.martenson@murex.com>]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

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

[-- Attachment #2.1: Type: text/plain, Size: 578 bytes --]

*******************************

This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.

[-- Attachment #2.2: Type: text/html, Size: 1143 bytes --]