From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22790: 24.5; Infinite loop involving malloc called from signal handler Date: Fri, 04 Mar 2016 11:42:04 +0200 Message-ID: <838u1yzij7.fsf@gnu.org> References: <83povmgfnn.fsf@gnu.org> <22228.22862.708667.152490@guava.gson.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457084602 2145 80.91.229.3 (4 Mar 2016 09:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2016 09:43:22 +0000 (UTC) Cc: 22790@debbugs.gnu.org To: Andreas Gustafsson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 04 10:43:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1abmGM-0001SK-Dh for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Mar 2016 10:43:10 +0100 Original-Received: from localhost ([::1]:39897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abmGL-0000kc-Lj for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Mar 2016 04:43:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abmGI-0000kE-5X for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:43:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abmGE-0005PT-3E for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:43:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abmGD-0005PP-V9 for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1abmGD-0005B9-Q7 for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Mar 2016 09:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22790 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 22790-submit@debbugs.gnu.org id=B22790.145708453919849 (code B ref 22790); Fri, 04 Mar 2016 09:43:01 +0000 Original-Received: (at 22790) by debbugs.gnu.org; 4 Mar 2016 09:42:19 +0000 Original-Received: from localhost ([127.0.0.1]:60829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abmFX-0005A5-6N for submit@debbugs.gnu.org; Fri, 04 Mar 2016 04:42:19 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50522) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abmFV-00059t-KB for 22790@debbugs.gnu.org; Fri, 04 Mar 2016 04:42:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abmFM-00055V-Ap for 22790@debbugs.gnu.org; Fri, 04 Mar 2016 04:42:12 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abmFM-00055R-6p; Fri, 04 Mar 2016 04:42:08 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2572 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1abmFL-0000as-Gu; Fri, 04 Mar 2016 04:42:07 -0500 In-reply-to: <22228.22862.708667.152490@guava.gson.org> (message from Andreas Gustafsson on Mon, 29 Feb 2016 16:44:30 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114382 Archived-At: > Date: Mon, 29 Feb 2016 16:44:30 +0200 > CC: Eli Zaretskii > From: Andreas Gustafsson > > The lockup happened again. There's still a SIGINT handler involved, > but at least there is only one of this time and not two recursive > ones. > > The full backtrace and some additional gdb output are included below, > but I would think this two-line excerpt should be sufficient to > identify the bug (or at least _a_ bug, if there is more than one): > > #9 0x00007f7ff60cc266 in printf () from /usr/lib/libc.so.12 > #10 0x00000000004db715 in handle_interrupt (in_signal_handler=true) at keyboard.c:10364 > > That is, printf() is not a signal safe function, so emacs is invoking > undefined behavior by calling it from a signal handler. Is this a GUI session or a text-mode terminal (a.k.a. "TTY") session? If the former, handle_interrupt is not called from a SIGINT handler. In any case, this code is run as part of the so-called "emergency escape", when you type C-g more than once while Emacs is busy doing something that cannot be interrupted. In that situation, we are way past the point where invoking undefined behavior is of any concern, because the only thing we can do then is auto-save and commit suicide. The printf call you see on the stack is asking the user whether to auto-save, and the next question is whether to abort. > > In any case, when this happens next, please use the procedure > > described in etc/DEBUG for locating the place where Emacs loops, and > > post that information. > > As you can see from the gdb transcript below, the "step" function > didn't work, but "stepi" shows it looping within libpthread. You need to use "finish", not "step" or "stepi". I don't think the loop can reasonably be inside libpthread, so you should try getting back to the Emacs application code and out of calls to library functions. Typing "finish" repeatedly until you are in some Emacs code is the way to achieve that. But this should be done without typing C-g first, because otherwise you might be forcibly taken out of the loop, and there's no easy way to return there. And I still don't understand why the SIGINT handler is in the picture. Did you type C-g when this lockup happened? > Even if you consider the backtrace to be suspect, code inspection > should suffice to show that the line > > printf ("Auto-save? (y or n) "); > > in src/keyboard.c can be executed from a signal handler. Indeed, it can. But I don't think this is the reason for the problem you are describing. That code cannot be entered unless you type C-g twice or more in a TTY session while Emacs is already in some un-interruptible loop or system call. It is that loop or system call that we need to identify in order to fix this problem. > (gdb) where > #0 0x00007f7ff6c083e2 in ?? () from /usr/lib/libpthread.so.1 > #1 0x00007f7ff6c08445 in ?? () from /usr/lib/libpthread.so.1 > #2 0x00007f7ff6c08848 in ?? () from /usr/lib/libpthread.so.1 > #3 0x00000000005c5486 in _malloc_internal (size=65536) at gmalloc.c:929 > #4 0x00000000005c54fc in malloc (size=65536) at gmalloc.c:953 > #5 0x00007f7ff60ed28c in __smakebuf () from /usr/lib/libc.so.12 > #6 0x00007f7ff60ed125 in __swsetup () from /usr/lib/libc.so.12 > #7 0x00007f7ff60cde92 in __vfprintf_unlocked () from /usr/lib/libc.so.12 > #8 0x00007f7ff60d1258 in vfprintf () from /usr/lib/libc.so.12 > #9 0x00007f7ff60cc266 in printf () from /usr/lib/libc.so.12 > #10 0x00000000004db715 in handle_interrupt (in_signal_handler=true) at keyboard.c:10364 > #11 0x00000000004db63e in handle_interrupt_signal (sig=2) at keyboard.c:10288 > #12 0x00000000004e8b63 in deliver_process_signal (sig=2, handler=0x4db5f1 ) at sysdep.c:1570 > #13 0x00000000004db65a in deliver_interrupt_signal (sig=2) at keyboard.c:10295 > #14 > #15 0x00007f7ff6c083e2 in ?? () from /usr/lib/libpthread.so.1 > #16 0x00007f7ff6c08445 in ?? () from /usr/lib/libpthread.so.1 > #17 0x00007f7ff6c08848 in ?? () from /usr/lib/libpthread.so.1 > #18 0x00000000005c5486 in _malloc_internal (size=1000) at gmalloc.c:929 > #19 0x00000000005c54fc in malloc (size=1000) at gmalloc.c:953 > #20 0x0000000000534f0d in xmalloc (size=1000) at alloc.c:677 > #21 0x000000000057968f in Fprinc (object=8564569, printcharfun=11946034) at print.c:656 > #22 0x000000000057a544 in print_error_message (data=41076294, stream=11944965, context=0x0, caller=11946034) at print.c:919 > #23 0x000000000057a238 in Ferror_message_string (obj=41076294) at print.c:844 > #24 0x000000000050e40e in auto_save_error (error_val=41076294) at fileio.c:5425 > #25 0x000000000055787a in internal_condition_case (bfun=0x50e477 , handlers=11946082, hfun=0x50e3bf ) at eval.c:1345 > #26 0x000000000050eb76 in Fdo_auto_save (no_message=11946082, current_only=11946034) at fileio.c:5672 > #27 0x00000000004cde3c in read_char (commandflag=1, map=41075894, prev_event=11946034, used_mouse_menu=0x7f7fffff9c0f, end_time=0x0) at keyboard.c:2751 > #28 0x00000000004d932a in read_key_sequence (keybuf=0x7f7fffff9df0, bufsize=30, prompt=11946034, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9089 > #29 0x00000000004cb5b0 in command_loop_1 () at keyboard.c:1453 > #30 0x0000000000557882 in internal_condition_case (bfun=0x4cb1f1 , handlers=12016002, hfun=0x4cab3b ) at eval.c:1348 > #31 0x00000000004caf5d in command_loop_2 (ignore=11946034) at keyboard.c:1178 > #32 0x00000000005570b5 in internal_catch (tag=12108690, func=0x4caf37 , arg=11946034) at eval.c:1112 > #33 0x00000000004caec0 in command_loop () at keyboard.c:1149 > #34 0x00000000004ca737 in recursive_edit_1 () at keyboard.c:778 > #35 0x00000000005017dd in read_minibuf (map=40555366, initial=37407873, prompt=18302785, expflag=false, histvar=12034962, histpos=0, defalt=11946034, allow_props=false, inherit_input_method=false) at minibuf.c:674 > #36 0x0000000000501ffd in Fread_from_minibuffer (prompt=18302785, initial_contents=37407873, keymap=40555366, read=11946034, hist=12034962, default_value=11946034, inherit_input_method=11946034) at minibuf.c:957 > #37 0x000000000055ab18 in Ffuncall (nargs=8, args=0x7f7fffffa398) at eval.c:2837 > #38 0x0000000000599506 in exec_byte_code (bytestr=9425233, vector=9425269, maxdepth=72, args_template=8200, nargs=8, args=0x7f7fffffa918) at bytecode.c:916 This tells the following story: . Emacs was running some byte code . that byte code tried to read from the minibuffer, probably after asking some question or prompting for some input . as part of that prompt, Emacs attempted to auto-save modified buffers . the auto-save attempt signaled an error . Emacs wanted to display the error message, and called malloc . then somehow SIGINT was delivered Does this match what you were doing? Any reason why auto-saving could fail (some filesystem that could be off-line, for example)? And where did that SIGINT come from? Thanks.