From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "John W. Eaton" Newsgroups: gmane.emacs.devel Subject: Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu) Date: Sat, 25 Feb 2006 02:45:04 -0500 Message-ID: <17408.2816.556166.916490@segfault.lan> References: <17403.34595.452779.27043@segfault.lan> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1140865437 30955 80.91.229.2 (25 Feb 2006 11:03:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2006 11:03:57 +0000 (UTC) Cc: emacs-devel@gnu.org, "John W. Eaton" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 25 12:03:55 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FCxDO-0002p1-4o for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2006 12:03:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FCxDP-0007uu-Pc for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2006 06:03:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FCu7F-0000mf-4t for emacs-devel@gnu.org; Sat, 25 Feb 2006 02:45:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FCu7C-0000jp-NH for emacs-devel@gnu.org; Sat, 25 Feb 2006 02:45:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FCu7C-0000jH-C9 for emacs-devel@gnu.org; Sat, 25 Feb 2006 02:45:18 -0500 Original-Received: from [144.92.13.31] (helo=mail.cae.wisc.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FCu7N-0002ce-6W; Sat, 25 Feb 2006 02:45:29 -0500 Original-Received: from portkey.cae.wisc.edu (portkey.cae.wisc.edu [144.92.13.118]) by mail.cae.wisc.edu (8.13.4/8.13.4) with ESMTP id k1P7j7UO002500; Sat, 25 Feb 2006 01:45:07 -0600 (CST) Original-Received: from segfault.lan (24-54-183-118.pittpa.adelphia.net [24.54.183.118]) (authenticated bits=0) by portkey.cae.wisc.edu (8.13.4/8.13.4/Debian-3) with ESMTP id k1P7j6il009408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Feb 2006 01:45:06 -0600 Original-To: rms@gnu.org In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.1 X-CAE-MailScanner-Information: Please contact security@engr.wisc.edu if this message contains a virus or has been corrupted in delivery. X-CAE-MailScanner: Found to be clean (benji) X-Mailman-Approved-At: Sat, 25 Feb 2006 06:02:46 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50950 Archived-At: On 24-Feb-2006, Richard Stallman wrote: | I don't think malloc is failing to allocate memory here, but something | is causing x_catch_errors_unwind to be called without a matching call | to x_catch_errors. | | It does look that way. But x_catch_errors_unwind was called from the | specpdl, and nothing ever puts it on the specpdl except x_catch_errors. | So something very very strange is happening. | | I just looked at every call to x_catch_errors, and none of them seems | to be able to exit without a subsequent call to x_uncatch_errors which | should unwind it. | | Can you examine the innermost specpdl bindings and see what | variables they bind? Also, please examine a few slots | just beyond the specpdl_ptr, slots which were unwound recently. | What variables or unwind functions do they use? Do you mean something like the following? Program received signal SIGSEGV, Segmentation fault. x_catch_errors_unwind (dummy=9571361) at /scratch/jwe/src/emacs/src/xterm.c:7543 7543 Display *dpy = x_error_message->dpy; (gdb) p *(specpdl_ptr-5) $1 = { symbol = 25233173, old_value = 9571409, func = 0, unused = 14128919392575862 } (gdb) p *(specpdl_ptr-4) $2 = { symbol = 10047041, old_value = 9571361, func = 0, unused = 127979076609647 } (gdb) p *(specpdl_ptr-3) $3 = { symbol = 15310353, old_value = 9571361, func = 0, unused = 7089075026933016948 } (gdb) p *(specpdl_ptr-2) $4 = { symbol = 15310401, old_value = 9571361, func = 0, unused = 7521905712077829995 } (gdb) p *(specpdl_ptr-1) $5 = { symbol = 9682081, old_value = 9572340, func = 0, unused = 7018969065866813815 } (gdb) p *(specpdl_ptr-0) $6 = { symbol = 9571313, old_value = 9571313, func = 0x4807c0 , unused = 7074422071709478245 } (gdb) p *(specpdl_ptr+1) $7 = { symbol = 10046849, old_value = 9571313, func = 0, unused = 7305790112002241125 } (gdb) p *(specpdl_ptr+2) $8 = { symbol = 10046897, old_value = 25232549, func = 0, unused = 7305790112002241125 } (gdb) p *(specpdl_ptr+3) $9 = { symbol = 10436065, old_value = 9571313, func = 0, unused = 20 } (gdb) p *(specpdl_ptr+4) $10 = { symbol = 9990977, old_value = 24405347, func = 0, unused = 13 } (gdb) p *(specpdl_ptr+5) $11 = { symbol = 9714577, old_value = 9571361, func = 0, unused = 1701734764 } If not, then will you please tell me precisely how you would like for me to do this? I'm not very familiar with Emacs internals. In any case, I don't see anything useful there. Maybe you will. However, as I was looking at the following loop unbind_to in eval.c, it occurred to me that one way the x_catch_errors_unwind function could be called twice in succession would be if specpdl_ptr is incremented by the addition of additional bindings while the loop is running (by some other code that is misbehaving while manipulating the specpdl array). In that case, it seems that the the entry for x_catch_errors_unwind would remain on the stack, to be executed again. I'm not sure how to determine whether that is what is happening, or if it is, how to determine where specpdl_ptr is being changed without being reset correctly. while (specpdl_ptr != specpdl + count) { /* Copy the binding, and decrement specpdl_ptr, before we do the work to unbind it. We decrement first so that an error in unbinding won't try to unbind the same entry again, and we copy the binding first in case more bindings are made during some of the code we run. */ struct specbinding this_binding; this_binding = *--specpdl_ptr; if (this_binding.func != 0) (*this_binding.func) (this_binding.old_value); /* If the symbol is a list, it is really (SYMBOL WHERE . CURRENT-BUFFER) where WHERE is either nil, a buffer, or a frame. If WHERE is a buffer or frame, this indicates we bound a variable that had a buffer-local or frame-local binding. WHERE nil means that the variable had the default value when it was bound. CURRENT-BUFFER is the buffer that was current when the variable was bound. */ else if (CONSP (this_binding.symbol)) { Lisp_Object symbol, where; symbol = XCAR (this_binding.symbol); where = XCAR (XCDR (this_binding.symbol)); if (NILP (where)) Fset_default (symbol, this_binding.old_value); else if (BUFFERP (where)) set_internal (symbol, this_binding.old_value, XBUFFER (where), 1); else set_internal (symbol, this_binding.old_value, NULL, 1); } else { /* If variable has a trivial value (no forwarding), we can just set it. No need to check for constant symbols here, since that was already done by specbind. */ if (!MISCP (SYMBOL_VALUE (this_binding.symbol))) SET_SYMBOL_VALUE (this_binding.symbol, this_binding.old_value); else set_internal (this_binding.symbol, this_binding.old_value, 0, 1); } } jwe