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

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

[Elias Martenson]

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


Build 2783e0e3899cf92910e97dc8bfda3e47b3df1478 with default options.

Start emacs -nw -Q

Press C-g

This causes the application to crash immediately.


In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.5)
 of 2016-12-12 built on em-desktop
Repository revision: 2783e0e3899cf92910e97dc8bfda3e47b3df1478
Recent messages:
Loading /home/emartenson/.emacs.d/murex-mail.el (source)...done
Loading /home/emartenson/.emacs.d/murex-slime.el (source)...done
Loading /home/emartenson/.emacs.d/view-defect.el (source)...done
Loading /home/emartenson/.emacs.d/murex.el (source)...done
Loading /home/emartenson/.emacs.d/project-settings.el (source)...done
Loading /home/emartenson/.emacs.d/em-multi-edit.el (source)...done
Loading /home/emartenson/.emacs.d/em-blogger.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]
funcall-interactively: End of buffer

Configured using:
 'configure CFLAGS=-g --prefix=/home/emartenson/src/emacs/dist'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LIBSYSTEMD

Important settings:
  value of $LANG: en_SG.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  paredit-mode: t
  guide-key-mode: t
  winner-mode: t
  elisp-slime-nav-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow sort flyspell ispell mail-extr emacsbug sendmail term/xterm
xterm paredit warnings server cc-mode-expansions cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
company-clang company-template company flycheck rx auto-complete-clang
auto-complete gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-calendar gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
rfc822 mml mml-sec epa epg mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util rmail rmail-loaddefs mail-utils mm-decode mm-bodies
mm-encode gnus-calendar-org org-capture ical-event-reply ical-event
eieio-compat org-import-icalendar eudcb-ldap eudc cus-edit eudc-vars
ldap outlook-style outlook-style-muse-editor muse-html muse-xml-common
muse-protocols muse-regexps muse muse-nested-tags muse-publish
org-caldav icalendar diary-lib diary-loaddefs org-id ox-latex
ox-icalendar ox-html ox-ascii ox-publish ox org-element
the-org-mode-expansions org org-macro org-footnote org-pcomplete
org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval
org-compat org-macs org-loaddefs find-func cal-menu calendar
cal-loaddefs url-dav xml projectile ibuf-ext ibuffer ibuffer-loaddefs
expand-region text-mode-expansions er-basic-expansions
expand-region-core expand-region-custom diminish guide-key s popwin dash
gnu-apl-mode gnu-apl-osx-workaround gnu-apl-documentation
gnu-apl-refdocs-bsd-license gnu-apl-follow gnu-apl-plot
gnu-apl-spreadsheet ses unsafep gnu-apl-editor gnu-apl-interactive
gnu-apl-input gnu-apl-symbols quail gnu-apl-network gnu-apl-util w3m
doc-view jka-compr dired dired-loaddefs image-mode timezone w3m-hist
w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image w3m-proc
w3m-util wid-edit tex-mode winner em-translate popup json map
http-post-simple url-http tls gnutls url-auth mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm subr-x puny url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap ielm elisp-slime-nav slime-indentation
slime-cl-indent cl-indent slime-mrepl inferior-slime slime-asdf grep
slime-tramp tramp tramp-compat tramp-loaddefs trampver ucs-normalize
shell pcomplete parse-time format-spec slime-fancy slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree slime-scratch slime-presentations advice
bridge slime-mdot-fu slime-enclosing-context slime-fuzzy
slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl elp slime-parse slime
derived gud apropos arc-mode archive-mode noutline outline easy-mmode pp
hyperspec thingatpt browse-url slime-autoloads ggtags etags xref project
compile comint ansi-color ring ewoc edmacro kmacro cl finder-inf
tex-site kotl-loaddefs info package epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date paren
cus-start cus-load mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 702625 24255)
 (symbols 48 58858 0)
 (miscs 40 97 244)
 (strings 32 142031 19572)
 (string-bytes 1 4638361)
 (vectors 16 71231)
 (vector-slots 8 1106490 5578)
 (floats 8 723 950)
 (intervals 56 392 0)
 (buffers 976 14))

[-- 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 --]

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

[Eli Zaretskii]

> From: Elias Martenson <elias.martenson@murex.com>
> Date: Mon, 12 Dec 2016 12:33:01 +0800
> 
> Build 2783e0e3899cf92910e97dc8bfda3e47b3df1478 with default options.
> 
> Start emacs -nw -Q
> 
> Press C-g
> 
> This causes the application to crash immediately.

Doesn't happen to me.

Can you run this under GDB and show the backtrace from the crash?

Thanks.

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

[Elias Martenson]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: Elias Martenson <elias.martenson@murex.com>
> > Date: Mon, 12 Dec 2016 12:33:01 +0800
> > 
> > Build 2783e0e3899cf92910e97dc8bfda3e47b3df1478 with default options.
> > 
> > Start emacs -nw -Q
> > 
> > Press C-g
> > 
> > This causes the application to crash immediately.
> 
> Doesn't happen to me.
> 
> Can you run this under GDB and show the backtrace from the crash?

It still happens on a completely fresh checkout and install of
8db7b65d66f01e90a05cc9f11c67667233d84ca0

Here is the stack trace:

Thread 1 "emacs" received signal SIGINT, Interrupt.
0x00007fffef71f18c in pselect () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x00007fffef71f18c in pselect () at /usr/lib/libc.so.6
#1  0x000000000069fd6b in xg_select (fds_lim=8, rfds=0x7fffffffdcd0, wfds=0x7fffffffdc50, efds=0x0, timeout=0x7fffffffdc30, sigmask=0x0) at xgselect.c:116
        all_rfds = {fds_bits = {192, 0 <repeats 15 times>}}
        all_wfds = {fds_bits = {0 <repeats 16 times>}}
        tmo = {tv_sec = 0, tv_nsec = 140737488345200}
        tmop = 0x7fffffffdc30
        context = 0x2d825d0
        have_wfds = true
        gfds_buf = 
            {{fd = 7, events = 1, revents = 0}, {fd = 6560509, events = 0, revents = 0}, {fd = -10080, events = 32767, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 1030, events = 0, revents = 0}, {fd = 42, events = 0, revents = 0}, {fd = 11055605, events = 0, revents = 0}, {fd = 11055572, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 88, events = 0, revents = 0}, {fd = 12167591, events = 0, revents = 0}, {fd = 11055572, events = 0, revents = 0}, {fd = 12167420, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 10, revents = 0}, {fd = 12772560, events = 0, revents = 0}, {fd = -11112, events = 32767, revents = 0}, {fd = 5573343, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 12772565, events = 0, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 12772560, events = 0, revents = 0}, {fd = 21486901, events = 0, revents = 0}, {fd = -11064, events = 32767, revents = 0}, {fd = 5570466, events = 0, revents = 0}, {fd = 21486901, events = 0, revents = 0}, {fd = -11040, events = 32767, revents = 0}, {fd = 5570466, events = 0, revents = 0}, {fd = 9, events = 0, revents = 0}, {fd = 5572836, events = 0, revents = 0}, {fd = 2, events = 0, revents = 0}, {fd = 13300048, events = 0, revents = 0}, {fd = 6281605, events = 0, revents = 0}, {fd = 45984, events = 0, revents = 0}, {fd = -136433516, events = 32767, revents = 0}, {fd = 5568885, events = 0, revents = 0}, {fd = 305, events = 0, revents = 0}, {fd = -134537216, events = 32767, revents = 0}, {fd = -268357864, events = 32767, revents = 0}, {fd = -268349704, events = 32767, revents = 0}, {fd = -136431405, events = 32767, revents = 0}, {fd = 305, events = 0, revents = 0}, {fd = -268349704, events = 32767, revents = 0}, {fd = -134537216, events = 32767, revents = 0}, {fd = -10792, events = 32767, revents = 0}, {fd = -10796, events = 32767, revents = 0}, {fd = -136433077, events = 32767, revents = 0}, {fd = 4242610, events = 0, revents = 0}, {fd = 4199752, events = 0, revents = 0}, {fd = -10792, events = 32767, revents = 0}, {fd = 2111285930, events = 0, revents = 0}, {fd = 26, events = 0, revents = 0}, {fd = -268349704, events = 32767, revents = 0}, {fd = -10576, events = 32767, revents = 0}, {fd = -268357864, events = 32767, revents = 0}, {fd = -10796, events = 32767, revents = 0}, {fd = -10592, events = 32767, revents = 0}, {fd = -135176416, events = 32767, revents = 0}, {fd = 106, events = 0, revents = 0}, {fd = 47427648, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = -134224792, events = 32767, revents = 0}, {fd = -10432, events = 32767, revents = 0}, {fd = -135175304, events = 32767, revents = 0}, {fd = 5, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = -10392, events = 32767, revents = 0}, {fd = -136430111, events = 32767, revents = 0}, {fd = 49, events = 0, revents = 0}, {fd = 22169539, events = 0, revents = 0}, {fd = 21486901, events = 0, revents = 0}, {fd = 9562752, events = 0, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = -10528, events = 32767, revents = 0}, {fd = 6138465, events = 0, revents = 0}, {fd = 13743104, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = -10576, events = 32767, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 257, events = 0, revents = 0}, {fd = -11304, events = 32767, revents = 0}, {fd = 0, events = 6, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 11, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = -10528, events = 32767, revents = 0}, {fd = 28272, events = 0, revents = 0}, {fd = 4294032, events = 0, revents = 0}, {fd = -10400, events = 32767, revents = 0}, {fd = 6141648, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 28272, events = 0, revents = 0}, {fd = 1, events = 135, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = 13743104, events = 0, revents = 0}, {fd = 13254064, events = 0, revents = 0}, {fd = -11392, events = 32767, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 13282336, events = 0, revents = 0}, {fd = 5568885, events = 0, revents = 0}, {fd = 28272, events = 0, revents = 0}, {fd = -10352, events = 32767, revents = 0}, {fd = 6140345, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 5573208, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = -10256, events = 32767, revents = 0}, {fd = 6144162, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 28272, events = 0, revents = 0},
{fd = 5, events = 0, revents = 0}, {fd = 6, events = 0, revents = 0}, {fd = 13251680, events = 0, revents = 0}, {fd = -10248, events = 32767, revents = 0}, {fd = 5573343, events = 0, revents = 0}, {fd = 13282336, events = 0, revents = 0}}
        gfds = 0x7fffffffd3e0
        gfds_size = 128
        n_gfds = 1
        retval = 0
        our_fds = 0
        max_fds = 7
        context_acquired = true
        i = 1
        nfds = 0
        tmo_in_millisec = -1
        must_free = 0
        need_to_dispatch = 35
#2  0x0000000000676dad in really_call_select (arg=0x7fffffffda20) at thread.c:498
        sa = 0x7fffffffda20
        self = 0xcc69e0 <primary_thread>
#3  0x00000000005d4a02 in flush_stack_call_func (func=0x676d51 <really_call_select>, arg=0x7fffffffda20) at alloc.c:5137
        end = 0x7fffffffd9a0
        self = 0xcc69e0 <primary_thread>
#4  0x0000000000676e2b in thread_select (func=0x69f84f <xg_select>, max_fds=7, rfds=0x7fffffffdcd0, wfds=0x7fffffffdc50, efds=0x0, timeout=0x7fffffffdc30, sigmask=0x0)
    at thread.c:517
        sa = 
          {func = 0x69f84f <xg_select>, max_fds = 7, rfds = 0x7fffffffdcd0, wfds = 0x7fffffffdc50, efds = 0x0, timeout = 0x7fffffffdc30, sigmask = 0x0, result = -1}
#5  0x0000000000651168 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
    at process.c:5345
        process_skipped = false
        channel = 1024
        nfds = 0
        Available = {fds_bits = {64, 0 <repeats 15 times>}}
        Writeok = {fds_bits = {0 <repeats 16 times>}}
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 4
        proc = 47321728
        timeout = {tv_sec = 9, tv_nsec = 484656783}
        end_time = {tv_sec = 1481596880, tv_nsec = 100278958}
        timer_delay = {tv_sec = 9, tv_nsec = 484656783}
        got_output_end_time = {tv_sec = 1481596880, tv_nsec = 100278958}
        wait = TIMEOUT
        got_some_output = -1
        retry_for_async = false
        count = 3
        now = {tv_sec = 0, tv_nsec = -1}
#6  0x00000000004252be in sit_for (timeout=122, reading=true, display_option=1)
    at dispnew.c:5763
        sec = 30
        nsec = 0
        do_display = true
#7  0x000000000055bc48 in read_char (commandflag=1, map=18488707, prev_event=0, used_mouse_menu=0x7fffffffe24f, end_time=0x0) at keyboard.c:2722
        tem0 = 5568885
        timeout = 30
        delay_level = 4
        buffer_size = 1
        c = 0
        jmpcount = 3
        local_getcjmp = 
                {{__jmpbuf = {0, -1720637353449548036, 4294032, 140737488349360, 0, 0, -1720637351413213444, 1720636901125723900}, __mask_was_saved = 0, __saved_mask = {__val = {20304512, 13254064, 6140185, 0, 140737488347280, 5568885, 18152640, 13254064, 5703904, 0, 140737488347328, 5568885, 19983315, 140737488347424, 6272424, 0}}}}
        save_jump = 
                {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
        tem = 18488707
        save = 0
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = false
        orig_kboard = 0x2d23870
#8  0x0000000000568714 in read_key_sequence (keybuf=0x7fffffffe400, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9136
        interrupted_kboard = 0x2d23870
        interrupted_frame = 0xd28688 <bss_sbrk_buffer+400168>
        key = 4545089
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = 5
        count = 3
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = 18488707
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 14043411, map = 14043411, start = 0, end = 0}
        keytran = {parent = 13732419, map = 13732419, start = 0, end = 0}
        indec = {parent = 14043443, map = 14043443, start = 0, end = 0}
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0xd1b400 <bss_sbrk_buffer+346272>
        fake_prefixed_keys = 0
#9  0x0000000000558939 in command_loop_1 () at keyboard.c:1373
        cmd = 140737488348496
        keybuf = 
          {0, 29328, 8321642624, 0, 13251856, 29328, 288, 13283392, 13251856, 0, 140737488348320, 6271814, 4294967296, 140737488348352, 13254064, 0, 0, 140737488348320, 5568885, 0, 140737488348416, 6272424, 14045523, 3, 13254064, 29328, 0, 140737488348400, 5568885, 0}
        i = 0
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = false
#10 0x00000000005f64a5 in internal_condition_case (bfun=0x558528 <command_loop_1>, handlers=19680, hfun=0x557d15 <cmd_error>) at eval.c:1336
        val = 5568885
        c = 0x2d3af10
#11 0x0000000000558232 in command_loop_2 (ignore=0) at keyboard.c:1115
        val = 0
#12 0x00000000005f5d72 in internal_catch (tag=47472, func=0x558209 <command_loop_2>, arg=0) at eval.c:1101
        val = 5568885
        c = 0x2d23940
#13 0x00000000005581d4 in command_loop () at keyboard.c:1094
#14 0x00000000005578f0 in recursive_edit_1 () at keyboard.c:700
        count = 1
        val = 140737488348800
#15 0x0000000000557a6c in Frecursive_edit () at keyboard.c:771
        count = 0
        buffer = 0
#16 0x0000000000555867 in main (argc=3, argv=0x7fffffffe8b8) at emacs.c:1686
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = false
        skip_args = 1
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        disable_aslr = false
        rlim = {rlim_cur = 8720384, rlim_max = 18446744073709551615}
        sockfd = -1

[-- 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 --]

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

[Elias Martenson]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't happen to me.
>
> Can you run this under GDB and show the backtrace from the crash?

I'm sorry, the previous stack trace I posted was from the interrupt
signal.

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)
                #16 0x0000000000568714 read_key_sequence (emacs-26.0.50)
                #17 0x0000000000558939 command_loop_1 (emacs-26.0.50)
                #18 0x00000000005f64a5 internal_condition_case (emacs-26.0.50)
                #19 0x0000000000558232 command_loop_2 (emacs-26.0.50)
                #20 0x00000000005f5d72 internal_catch (emacs-26.0.50)
                #21 0x00000000005581d4 command_loop (emacs-26.0.50)
                #22 0x00000000005578f0 recursive_edit_1 (emacs-26.0.50)
                #23 0x0000000000557a6c Frecursive_edit (emacs-26.0.50)
                #24 0x0000000000555867 main (emacs-26.0.50)
                #25 0x00007fec15763291 __libc_start_main (libc.so.6)
                #26 0x00000000004185ba _start (emacs-26.0.50)
                
                Stack trace of thread 21461:
                #0  0x00007fec1582248d poll (libc.so.6)
                #1  0x00007fec1b119786 n/a (libglib-2.0.so.0)
                #2  0x00007fec1b11989c g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007fec1b1198e1 n/a (libglib-2.0.so.0)
                #4  0x00007fec1b1410d5 n/a (libglib-2.0.so.0)
                #5  0x00007fec1611e454 start_thread (libpthread.so.0)
                #6  0x00007fec1582b7df __clone (libc.so.6)

GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/emartenson/src/emacs/dist/bin/emacs-26.0.50...done.

warning: core file may not match specified executable file.
[New LWP 21460]
[New LWP 21461]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `dist/bin/emacs -nw -Q'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fec16127f5f in raise () from /usr/lib/libpthread.so.0
[Current thread is 1 (Thread 0x7fec1e015a00 (LWP 21460))]
(gdb) bt full
#0  0x00007fec16127f5f in raise () at /usr/lib/libpthread.so.0
#1  0x0000000000553c66 in terminate_due_to_signal (sig=11, backtrace_limit=40)
    at emacs.c:394
#2  0x00000000005783c1 in handle_fatal_signal (sig=11) at sysdep.c:1685
#3  0x0000000000578392 in deliver_thread_signal (sig=11, handler=0x5783a7 <handle_fatal_signal>) at sysdep.c:1659
        old_errno = 4
#4  0x00000000005783f8 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1697
#5  0x00000000005785ae in handle_sigsegv (sig=11, siginfo=0xc8c930 <sigsegv_stack+7152>, arg=0xc8c800 <sigsegv_stack+6848>) at sysdep.c:1782
        fatal = false
#6  0x00007fec16128080 in <signal handler called> () at /usr/lib/libpthread.so.0
#7  0x00007fec161296a0 in __lll_unlock_elision () at /usr/lib/libpthread.so.0
#8  0x0000000000677a94 in sys_mutex_unlock (mutex=0xcc6b20 <global_lock>)
    at systhread.c:119
#9  0x000000000067638d in release_global_lock () at thread.c:50
#10 0x0000000000676d75 in really_call_select (arg=0x7ffd4e656da0) at thread.c:497
        sa = 0x7ffd4e656da0
        self = 0xcc69e0 <primary_thread>
#11 0x00000000005d4a02 in flush_stack_call_func (func=0x676d51 <really_call_select>, arg=0x7ffd4e656da0) at alloc.c:5137
        end = 0x7ffd4e656d20
        self = 0xcc69e0 <primary_thread>
#12 0x0000000000676e2b in thread_select (func=0x69f84f <xg_select>, max_fds=7, rfds=0x7ffd4e657050, wfds=0x7ffd4e656fd0, efds=0x0, timeout=0x7ffd4e656fb0, sigmask=0x0)
    at thread.c:517
        sa = 
          {func = 0x69f84f <xg_select>, max_fds = 7, rfds = 0x7ffd4e657050, wfds = 0x7ffd4e656fd0, efds = 0x0, timeout = 0x7ffd4e656fb0, sigmask = 0x0, result = -1}
#13 0x0000000000651168 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0)
    at process.c:5345
        process_skipped = false
        channel = 0
        nfds = 5676853
        Available = {fds_bits = {80, 0 <repeats 15 times>}}
        Writeok = {fds_bits = {0 <repeats 16 times>}}
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 0
        proc = 75334272
        timeout = {tv_sec = 0, tv_nsec = 499974654}
        end_time = {tv_sec = 1481598290, tv_nsec = 297726035}
        timer_delay = {tv_sec = 0, tv_nsec = 499974654}
        got_output_end_time = {tv_sec = 1481598290, tv_nsec = 297726035}
        wait = TIMEOUT
        got_some_output = -1
        retry_for_async = false
        count = 3
        now = {tv_sec = 0, tv_nsec = -1}
#14 0x00000000004252be in sit_for (timeout=122, reading=true, display_option=1)
    at dispnew.c:5763
        sec = 30
        nsec = 0
        do_display = true
#15 0x000000000055bc48 in read_char (commandflag=1, map=19912227, prev_event=0, used_mouse_menu=0x7ffd4e6575cf, end_time=0x0) at keyboard.c:2722
        tem0 = 5568885
        timeout = 30
        delay_level = 4
        buffer_size = 1
        c = 0
        jmpcount = 3
        local_getcjmp = 
                {{__jmpbuf = {0, -8520776443860642955, 4294032, 140725918727216, 0, 0, -8520776443766271115, 8519265241542136693}, __mask_was_saved = 0, __saved_mask = {__val = {20304512, 13254064, 6140185, 0, 140725918725136, 5568885, 18152640, 13254064, 5703904, 0, 140725918725184, 5568885, 19983315, 140725918725280, 6272424, 0}}}}
        save_jump = 
                {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
        tem = 19912227
        save = 0
        previous_echo_area_message = 0
        also_record = 0
        reread = false
        recorded = false
        polling_stopped_here = false
        orig_kboard = 0x47da7f0
#16 0x0000000000568714 in read_key_sequence (keybuf=0x7ffd4e657780, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9136
        interrupted_kboard = 0x47da7f0
        interrupted_frame = 0xd28688 <bss_sbrk_buffer+400168>
        key = 4545089
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = 5
        count = 3
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = 19912227
        first_event = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 14043523, map = 14043523, start = 0, end = 0}
        keytran = {parent = 13732419, map = 13732419, start = 0, end = 0}
        indec = {parent = 14043571, map = 14043571, start = 0, end = 0}
        shift_translated = false
        delayed_switch_frame = 0
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0xd1b400 <bss_sbrk_buffer+346272>
        fake_prefixed_keys = 0
#17 0x0000000000558939 in command_loop_1 () at keyboard.c:1373
        cmd = 140725918726352
        keybuf = 
          {140725918726112, 6265093, 140725918726160, 4, 140725918726096, 515712, 3, 3, 0, 9575733, 140725918726160, 0, 140725918726192, 6263393, 0, 9588196, 13254064, 515712, 0, 140725918726192, 5568885, 0, 13254064, 5603198, 13254064, 140725918726240, 0, 140725918726256, 5568885, 5603001}
        i = 1
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = false
#18 0x00000000005f64a5 in internal_condition_case (bfun=0x558528 <command_loop_1>, handlers=19680, hfun=0x557d15 <cmd_error>) at eval.c:1336
        val = 5568885
        c = 0x47f1f00
#19 0x0000000000558232 in command_loop_2 (ignore=0) at keyboard.c:1115
        val = 2
#20 0x00000000005f5d72 in internal_catch (tag=47472, func=0x558209 <command_loop_2>, arg=0) at eval.c:1101
        val = 5568885
        c = 0x47da8c0
#21 0x00000000005581d4 in command_loop () at keyboard.c:1094
#22 0x00000000005578f0 in recursive_edit_1 () at keyboard.c:700
        count = 1
        val = 140725918726656
#23 0x0000000000557a6c in Frecursive_edit () at keyboard.c:771
        count = 0
        buffer = 0
#24 0x0000000000555867 in main (argc=3, argv=0x7ffd4e657c38) at emacs.c:1686
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = false
        skip_args = 1
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        disable_aslr = false
        rlim = {rlim_cur = 8720384, rlim_max = 18446744073709551615}
        sockfd = -1

[-- 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 --]

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

[Eli Zaretskii]

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

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

[Andreas Schwab]

On Dez 13 2016, Eli Zaretskii <eliz@gnu.org> wrote:

> Hmm...  Is calling pthread_mutex_unlock twice in a row, without an
> intervening call to pthread_mutex_lock, supposed to segfault?

It's undefined, so anything can happen.  Just don't do that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Elias Martenson <elias.martenson@murex.com>,  25178@debbugs.gnu.org
> Date: Tue, 13 Dec 2016 20:26:10 +0100
> 
> On Dez 13 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Hmm...  Is calling pthread_mutex_unlock twice in a row, without an
> > intervening call to pthread_mutex_lock, supposed to segfault?
> 
> It's undefined, so anything can happen.  Just don't do that.

At this point, I'd like to establish whether the fact Emacs does do it
could explain crashes reported by Elias which I cannot reproduce on a
different GNU/Linux system.

What I think happens is that C-g on a TTY produces a SIGINT that
interrupts the call to pselect and runs handle_interrupt, which then
longjmps back to read_char, which then calls thread_select.  But since
pselect inside the previous call to thread_select was interrupted, the
following call to acquire_global_lock was not done, and we are now
running with the global lock unlocked.  Then thread_select calls
release_global_lock which attempts to unlock the (unlocked) mutex.

The question is whether this is just bad, or causes the crash.  It
doesn't crash for me.

Thanks.

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

[Andreas Schwab]

On Dez 13 2016, Eli Zaretskii <eliz@gnu.org> wrote:

> At this point, I'd like to establish whether the fact Emacs does do it
> could explain crashes

Yes.

> It doesn't crash for me.

A perfectly valid undefined behaviour.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Elias Martenson]

[-- 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 --]

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

[Elias Martenson]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: Elias Martenson <elias.martenson@murex.com>,  25178@debbugs.gnu.org
> > Date: Tue, 13 Dec 2016 20:26:10 +0100
> > 
> > On Dez 13 2016, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > > Hmm...  Is calling pthread_mutex_unlock twice in a row, without an
> > > intervening call to pthread_mutex_lock, supposed to segfault?
> > 
> > It's undefined, so anything can happen.  Just don't do that.
> 
> At this point, I'd like to establish whether the fact Emacs does do it
> could explain crashes reported by Elias which I cannot reproduce on a
> different GNU/Linux system.
> 
> What I think happens is that C-g on a TTY produces a SIGINT that
> interrupts the call to pselect and runs handle_interrupt, which then
> longjmps back to read_char, which then calls thread_select.  But since
> pselect inside the previous call to thread_select was interrupted, the
> following call to acquire_global_lock was not done, and we are now
> running with the global lock unlocked.  Then thread_select calls
> release_global_lock which attempts to unlock the (unlocked) mutex.
> 
> The question is whether this is just bad, or causes the crash.  It
> doesn't crash for me.

I'm using Arch Linux, which tends to use quite bleeding edge versions
pretty much everything.

Since I don't recall seeing this issue until recently, I'm
suspecting—although I have no proof of this—that they might have
recently introduced a change that causes this to crash instead of
silently accepting it, perhaps as a way to find bugs like this?

Regards,
Elias
*******************************

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.

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

[Eli Zaretskii]

> From: Elias Martenson <elias.martenson@murex.com>
> CC: <25178@debbugs.gnu.org>
> Date: Wed, 14 Dec 2016 11:09:12 +0800
> 
> > 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.

I'm not asking if this is undefined behavior; it clearly is.  I'm
asking whether the second of these two calls is actually the one that
crashes Emacs with SIGSEGV.  IOW, does the crash happen inside the
second call to pthread_mutex_unlock?  And the next question would be
why doesn't it crash for me on another GNU/Linux system?

Thanks.

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

[Elias Martenson]

‾汅⁩慚敲獴楫⁩攼楬䁺湧⹵牯㹧眠楲整㩳㸊ਠ‾‾牆浯›汅慩⁳慍瑲湥潳攼楬獡洮牡整獮湯浀牵硥挮浯ਾ‾‾䍃›㈼ㄵ㠷摀扥畢獧朮畮漮杲ਾ‾‾慄整›敗Ɽㄠ‴敄⁣〲㘱ㄠ㨱㤰ㄺ′〫〸ਰ‾‾㸊㸠㸠匠牴湡敧祬‬⁉潤❮⁴敳⁥桴獩漠桴⁥乇⽕楌畮⁸祳瑳浥琠桷捩⁨⁉慨敶㸊㸠㸠愠捣獥ⱳ愠瑬潨杵⁨浅捡⁳敤楦楮整祬挠污獬瀠桴敲摡浟瑵硥畟汮捯睴捩⁥湩㸊㸠㸠愠爠睯椠桴⁥捳湥牡潩漠⁦桴獩戠杵爠灥牯⹴†獉琠楨⁳潳敭挠慨杮⁥湩㸊㸠㸠氠瑡獥⁴敶獲潩獮漠⁦汧扩㽣㸊㸠ਠ‾‾慃汬湩⁧瑰牨慥彤畭整彸湵潬正⤨琠楷散栠獡琠敢甠摮晥湩摥戠桥癡潩牵‮湉㸊㸠映捡ⱴ椠⁴慣敮敶⁲潷歲‮浉条湩⁥桷瑡眠畯摬栠灡数晩愠搠晩敦敲瑮琠牨慥੤‾‾慣汬摥瀠桴敲摡浟瑵硥江捯⡫
湯琠敨洠瑵硥戠瑥敷湥琠潷琠敨琠潷甠汮捯੫‾‾慣汬⹳䤠桴瑡挠獡ⱥ礠畯搧戠⁥湵潬正湩⁧⁡畭整⁸敨灬戠⁹⁡楤晦牥湥ੴ‾‾桴敲摡眠楨档椠⁳扯楶畯汳⁹敶祲搠湡敧潲獵ਮ‾㸊䤠洧渠瑯愠歳湩⁧晩琠楨⁳獩甠摮晥湩摥戠桥癡潩㭲椠⁴汣慥汲⁹獩‮䤠洧㸊愠歳湩⁧桷瑥敨⁲桴⁥敳潣摮漠⁦桴獥⁥睴慣汬⁳獩愠瑣慵汬⁹桴⁥湯⁥桴瑡㸊挠慲桳獥䔠慭獣眠瑩⁨䥓升䝅⹖†佉ⱗ搠敯⁳桴⁥牣獡⁨慨灰湥椠獮摩⁥桴੥‾敳潣摮挠污潴瀠桴敲摡浟瑵硥畟汮捯㽫†湁⁤桴⁥敮瑸焠敵瑳潩潷汵⁤敢㸊眠票搠敯湳琧椠⁴牣獡⁨潦⁲敭漠湡瑯敨⁲乇⽕楌畮⁸祳瑳浥ਿ䤊栠癡⁥潮椠敤⹡䴠⁹湯祬朠敵獳椠⁳桴瑡椠❴⁳敢慣獵⁥景爠捥湥⁴档湡敧⁳湩氊扩瑰牨慥⹤䄠⁳⁉敭瑮潩敮⁤湩愠慥汲敩⁲敲汰ⱹ䄠捲⁨楌畮⁸整摮⁳潴戠੥湯琠敨戠敬摥湩⁧摥敧漠⁦桴湩獧ਮ刊来牡獤ਬ汅慩ੳ
*******************************

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.

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

[Eli Zaretskii]

> From: Elias Martenson <elias.martenson@murex.com>
> CC: <25178@debbugs.gnu.org>
> Date: Wed, 14 Dec 2016 11:09:12 +0800
> 
> 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.

Can you try the patch below and see if it stops the crashes?  With
this patch, I no longer see two calls to pthread_mutex_unlock in a
row.

Would people who know about signals and threads please eyeball this
patch and comment on whether it is correct, safe, etc.?  TIA.


diff --git a/src/keyboard.c b/src/keyboard.c
index 1fb1d49..f2ee313 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2571,6 +2571,9 @@ read_char (int commandflag, Lisp_Object map,
 	 so restore it now.  */
       restore_getcjmp (save_jump);
       pthread_sigmask (SIG_SETMASK, &empty_mask, 0);
+#if THREADS_ENABLED
+      maybe_reacquire_global_lock ();
+#endif
       unbind_to (jmpcount, Qnil);
       XSETINT (c, quit_char);
       internal_last_event_frame = selected_frame;
diff --git a/src/sysdep.c b/src/sysdep.c
index 3d2b9bd..5e5a605 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -765,6 +765,23 @@ unblock_child_signal (sigset_t const *oldset)
   pthread_sigmask (SIG_SETMASK, oldset, 0);
 }
 
+void
+block_interrupt_signal (sigset_t *oldset)
+{
+  sigset_t blocked;
+  sigemptyset (&blocked);
+  sigaddset (&blocked, SIGINT);
+  pthread_sigmask (SIG_BLOCK, &blocked, oldset);
+}
+
+/* Unblock SIGINT.  */
+
+void
+unblock_interrupt_signal (sigset_t const *oldset)
+{
+  pthread_sigmask (SIG_SETMASK, oldset, 0);
+}
+
 #endif	/* !MSDOS */
 \f
 /* Saving and restoring the process group of Emacs's terminal.  */
diff --git a/src/syssignal.h b/src/syssignal.h
index 3de83c7..d3b585c 100644
--- a/src/syssignal.h
+++ b/src/syssignal.h
@@ -25,6 +25,8 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 extern void init_signals (bool);
 extern void block_child_signal (sigset_t *);
 extern void unblock_child_signal (sigset_t const *);
+extern void block_interrupt_signal (sigset_t *);
+extern void unblock_interrupt_signal (sigset_t const *);
 extern void block_tty_out_signal (sigset_t *);
 extern void unblock_tty_out_signal (sigset_t const *);
 
diff --git a/src/thread.c b/src/thread.c
index e8cb430..e519558 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -24,6 +24,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include "buffer.h"
 #include "process.h"
 #include "coding.h"
+#include "syssignal.h"
 
 static struct thread_state primary_thread;
 
@@ -100,6 +101,23 @@ acquire_global_lock (struct thread_state *self)
   post_acquire_global_lock (self);
 }
 
+/* This is called from keyboard.c when it detects that SIGINT
+   interrupted thread_select before the current thread could acquire
+   the lock.  We must acquire the lock to prevent a thread from
+   running without holding the global lock, and to avoid repeated
+   calls to sys_mutex_unlock, which invokes undefined behavior.  */
+void
+maybe_reacquire_global_lock (void)
+{
+  if (current_thread->not_holding_lock)
+    {
+      struct thread_state *self = current_thread;
+
+      acquire_global_lock (self);
+      current_thread->not_holding_lock = 0;
+    }
+}
+
 \f
 
 static void
@@ -493,11 +511,20 @@ really_call_select (void *arg)
 {
   struct select_args *sa = arg;
   struct thread_state *self = current_thread;
+  sigset_t oldset;
 
+  block_interrupt_signal (&oldset);
+  self->not_holding_lock = 1;
   release_global_lock ();
+  unblock_interrupt_signal (&oldset);
+
   sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds,
 			   sa->timeout, sa->sigmask);
+
+  block_interrupt_signal (&oldset);
   acquire_global_lock (self);
+  self->not_holding_lock = 0;
+  unblock_interrupt_signal (&oldset);
 }
 
 int
diff --git a/src/thread.h b/src/thread.h
index 739069a..b044383 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -171,6 +171,13 @@ struct thread_state
      interrupter should broadcast to this condition.  */
   sys_cond_t *wait_condvar;
 
+  /* This thread might have released the global lock.  If so, this is
+     non-zero.  When a thread runs outside thread_select with this
+     flag non-zero, it means it has been interrupted by SIGINT while
+     in thread_select, and didn't have a chance of acquiring the lock.
+     It must do so ASAP.  */
+  int not_holding_lock;
+
   /* Threads are kept on a linked list.  */
   struct thread_state *next_thread;
 };
@@ -224,6 +231,7 @@ extern void unmark_threads (void);
 extern void finalize_one_thread (struct thread_state *state);
 extern void finalize_one_mutex (struct Lisp_Mutex *);
 extern void finalize_one_condvar (struct Lisp_CondVar *);
+extern void maybe_reacquire_global_lock (void);
 
 extern void init_threads_once (void);
 extern void init_threads (void);

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

[Elias Martenson]

‾汅⁩慚敲獴楫⁩攼楬䁺湧⹵牯㹧眠楲整㩳㸊ਠ‾‾牆浯›汅慩⁳慍瑲湥潳攼楬獡洮牡整獮湯浀牵硥挮浯ਾ‾‾䍃›㈼ㄵ㠷摀扥畢獧朮畮漮杲ਾ‾‾慄整›敗Ɽㄠ‴敄⁣〲㘱ㄠ㨱㤰ㄺ′〫〸ਰ‾‾㸊㸠䌠污楬杮瀠桴敲摡浟瑵硥畟汮捯⡫
睴捩⁥慨⁳潴戠⁥湵敤楦敮⁤敢慨楶畯⹲䤠੮‾‾慦瑣‬瑩挠湡渠癥牥眠牯⹫䤠慭楧敮眠慨⁴潷汵⁤慨灰湥椠⁦⁡楤晦牥湥⁴桴敲摡㸊㸠挠污敬⁤瑰牨慥彤畭整彸潬正⤨漠桴⁥畭整⁸敢睴敥睴桴⁥睴湵潬正㸊㸠挠污獬‮湉琠慨⁴慣敳‬潹❵⁤敢甠汮捯楫杮愠洠瑵硥栠汥⁰祢愠搠晩敦敲瑮㸊㸠琠牨慥⁤桷捩⁨獩漠癢潩獵祬瘠牥⁹慤杮牥畯⹳㸊ਠ‾慃潹⁵牴⁹桴⁥慰捴⁨敢潬⁷湡⁤敳⁥晩椠⁴瑳灯⁳桴⁥牣獡敨㽳†楗桴㸊琠楨⁳慰捴ⱨ䤠渠潬杮牥猠敥琠潷挠污獬琠瑰牨慥彤畭整彸湵潬正椠੡‾潲⹷ਊ❉敶琠楲摥椠ⱴ愠摮䤠愠潮⁷湵扡敬琠敲牰摯捵⁥桴⁥牰扯敬⹭吠慨歮⁳੡潬ⅴਊ‾潗汵⁤数灯敬眠潨欠潮⁷扡畯⁴楳湧污⁳湡⁤桴敲摡⁳汰慥敳攠敹慢汬琠楨ੳ‾慰捴⁨湡⁤潣浭湥⁴湯眠敨桴牥椠⁴獩挠牯敲瑣‬慳敦‬瑥⹣‿吠䅉ਮ䤊洧焠極整眠汥⵬敶獲摥漠桴⁥潴楰⁣景琠牨慥楤杮‬畢⁴潮⁴潳洠捵⁨湩琠敨椊瑮牥慮獬漠⁦浅捡ⱳ戠瑵䤠洧氠潯楫杮愠⁴瑩渠睯ਮ䤊搠慨敶愠渠湯琭捥湨捩污挠浯敭瑮琠潨杵ⱨ愠潢瑵琠敨映湵瑣潩੮湵汢捯彫湩整牲灵彴楳湧污⤨‮獁映牡愠⁳⁉慣整汬‬瑩搠敯湳琧搠桷瑡琠敨昊湵瑣潩慮敭猠杵敧瑳⁳瑩搠敯⹳䤠搧爠瑡敨⁲慮敭椠⁴敳彴楳湧污浟獡⡫Ⱙ猊湩散琠慨❴⁳桷瑡椠⁴潤獥ਮ
*******************************

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.

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

[npostavs]

tags 25178 fixed
close 25178 
quit

> Date: Mon, 19 Dec 2016 19:17:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Elias Martenson <elias.martenson@murex.com>
> > CC: <25178@debbugs.gnu.org>
> > Date: Mon, 19 Dec 2016 10:48:08 +0800
> > 
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > > 
> > > > From: Elias Martenson <elias.martenson@murex.com>
> > > > CC: <25178@debbugs.gnu.org>
> > > > Date: Wed, 14 Dec 2016 11:09:12 +0800
> > > > 
> > > 
> > > Can you try the patch below and see if it stops the crashes? With
> > > this patch, I no longer see two calls to pthread_mutex_unlock in a
> > > row.
> > 
> > I've tried it, and I am now unable to reproduce the problem. Thanks a
> > lot!
> 
> Thanks, pushed.  Please test.

I presume this can be considered fixed now.

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

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Date: Thu, 05 Jan 2017 18:39:28 -0500
> 
> I presume this can be considered fixed now.

Yes, thanks.