unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "John W. Eaton" <jwe@bevo.che.wisc.edu>
Cc: "John W. Eaton" <jwe@bevo.che.wisc.edu>
Subject: Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)
Date: Fri, 17 Feb 2006 03:04:38 -0500	[thread overview]
Message-ID: <17397.33686.218699.659071@segfault.lan> (raw)

On Mon, 13 Feb 2006, Richard M. Stallman wrote:

| He gave this crucial piece of information:
| 
|     In both gdb sessions I get:
| 
|     (gdb) p x_error_message
|     $1 = (struct x_error_message_stack *) 0x0
| 
| >From that, can you see a bug in your code?
| 
|     (gdb) xbacktrace 
|     "face-attr-match-p"
| 
| That ought to localize it pretty well too.

I'm also encountering a crash due to x_error_message == 0, here:

  (gdb) p x_error_message
  $1 = (struct x_error_message_stack *) 0x0
  (gdb) list
  7538
  7539    static Lisp_Object
  7540    x_catch_errors_unwind (dummy)
  7541         Lisp_Object dummy;
  7542    {
  7543      Display *dpy = x_error_message->dpy;
  7544      struct x_error_message_stack *tmp;
  7545
  7546      /* The display may have been closed before this function is called.
  7547         Check if it is still open before calling XSync.  */
  (gdb) xbacktrace
  "assoc-default"
  "set-auto-mode"
  "normal-mode"
  "after-find-file"
  "find-file-noselect-1"
  "find-file-noselect"
  "find-file-other-window"
  "command-line-1"
  "command-line"
  "normal-top-level"
  (gdb) where
  #0  x_catch_errors_unwind (dummy=13215333)
      at /scratch/jwe/src/emacs/src/xterm.c:7543
  #1  0x000000000050db2d in unbind_to (count=<value optimized out>,
      value=9546737) at /scratch/jwe/src/emacs/src/eval.c:3233
  #2  0x000000000053c778 in Fbyte_code (bytestr=70, vector=7317884, maxdepth=40)
      at /scratch/jwe/src/emacs/src/bytecode.c:716
  #3  0x000000000050eeab in funcall_lambda (fun=7317572, nargs=1,
      arg_vector=0x7ffffff35988) at /scratch/jwe/src/emacs/src/eval.c:3066
  #4  0x000000000050f456 in Ffuncall (nargs=<value optimized out>, args=0x6fa840)
      at /scratch/jwe/src/emacs/src/eval.c:2934
  #5  0x000000000053c904 in Fbyte_code (bytestr=10163713, vector=7319660,
      maxdepth=64) at /scratch/jwe/src/emacs/src/bytecode.c:694
  #6  0x000000000050eeab in funcall_lambda (fun=7318844, nargs=4,
      arg_vector=0x7ffffff35b48) at /scratch/jwe/src/emacs/src/eval.c:3066
  #7  0x000000000050f456 in Ffuncall (nargs=<value optimized out>, args=0x6fad38)
      at /scratch/jwe/src/emacs/src/eval.c:2934
  #8  0x000000000053c904 in Fbyte_code (bytestr=10412017, vector=7308220,
      maxdepth=48) at /scratch/jwe/src/emacs/src/bytecode.c:694
  #9  0x000000000050eeab in funcall_lambda (fun=7308036, nargs=1,
      arg_vector=0x7ffffff35cf8) at /scratch/jwe/src/emacs/src/eval.c:3066
  #10 0x000000000050f456 in Ffuncall (nargs=<value optimized out>, args=0x6f8300)
      at /scratch/jwe/src/emacs/src/eval.c:2934
  #11 0x000000000053c904 in Fbyte_code (bytestr=10081201, vector=787, maxdepth=0)
      at /scratch/jwe/src/emacs/src/bytecode.c:694
  #12 0x000000000050eeab in funcall_lambda (fun=8449212, nargs=1,
      arg_vector=0x7ffffff35ed8) at /scratch/jwe/src/emacs/src/eval.c:3066
  #13 0x000000000050f456 in Ffuncall (nargs=<value optimized out>, args=0x80ecb8)
      at /scratch/jwe/src/emacs/src/eval.c:2934
  #14 0x000000000053c904 in Fbyte_code (bytestr=9752577, vector=8425668,
      maxdepth=56) at /scratch/jwe/src/emacs/src/bytecode.c:694
  #15 0x000000000050eeab in funcall_lambda (fun=8424020, nargs=0,
      arg_vector=0x7ffffff36098) at /scratch/jwe/src/emacs/src/eval.c:3066
  #16 0x000000000050f456 in Ffuncall (nargs=<value optimized out>, args=0x808a50)
      at /scratch/jwe/src/emacs/src/eval.c:2934
  #17 0x000000000053c904 in Fbyte_code (bytestr=9699873, vector=8415588,
      maxdepth=48) at /scratch/jwe/src/emacs/src/bytecode.c:694
  #18 0x000000000050eeab in funcall_lambda (fun=8415364, nargs=0,
      arg_vector=0x7ffffff361d0) at /scratch/jwe/src/emacs/src/eval.c:3066
  #19 0x000000000050f14c in apply_lambda (fun=8415364, args=9546737, eval_flag=1)
      at /scratch/jwe/src/emacs/src/eval.c:2988
  #20 0x000000000050e810 in Feval (form=<value optimized out>)
      at /scratch/jwe/src/emacs/src/eval.c:2277
  #21 0x000000000050d587 in internal_condition_case (
      bfun=0x4a4700 <top_level_2>, handlers=9640161, hfun=0x4aa810 <cmd_error>)
      at /scratch/jwe/src/emacs/src/eval.c:1465
  #22 0x00000000004a473a in top_level_1 ()
      at /scratch/jwe/src/emacs/src/keyboard.c:1345
  #23 0x000000000050d437 in internal_catch (tag=<value optimized out>,
      func=0x4a4710 <top_level_1>, arg=9546737)
      at /scratch/jwe/src/emacs/src/eval.c:1211
  #24 0x00000000004a44db in command_loop ()
      at /scratch/jwe/src/emacs/src/keyboard.c:1302
  #25 0x00000000004a4591 in recursive_edit_1 ()
      at /scratch/jwe/src/emacs/src/keyboard.c:1000
  ---Type <return> to continue, or q <return> to quit---
  #26 0x00000000004a4693 in Frecursive_edit ()
      at /scratch/jwe/src/emacs/src/keyboard.c:1061
  #27 0x00000000004a372f in main (argc=2011, argv=0x7ffffff36a68)
      at /scratch/jwe/src/emacs/src/emacs.c:1789

I'm using the CVS Emacs sources, checked out Feb 16.  I'm generating
this error by running

  emacs -q long list of files to open ...

followed by grabbing the window with the mouse and moving it around
the screen rapidly while Emacs is loading the files.  I can usually
but not always cause Emacs to crash by doing this.

I was unable to reproduce the problem if I set a breakpoint in
x_catch_errors_unwind, so I made the following changes to xterm.c, to
trace the sequence of calls to x_catch_errors and
x_catch_errors_unwind, which it seems should always be paired.

Index: xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.897
diff -u -r1.897 xterm.c
--- xterm.c	14 Feb 2006 10:01:23 -0000	1.897
+++ xterm.c	17 Feb 2006 07:48:50 -0000
@@ -7508,6 +7508,9 @@
 void x_check_errors ();
 static Lisp_Object x_catch_errors_unwind ();
 
+static char xxxbuf[1000];
+static int xxxidx = 0;
+
 int
 x_catch_errors (dpy)
      Display *dpy;
@@ -7531,6 +7534,9 @@
 
   record_unwind_protect (x_catch_errors_unwind, dummy);
 
+  xxxbuf[xxxidx++] = 's';
+  xxxbuf[xxxidx] = 0;
+
   return count;
 }
 
@@ -7540,6 +7546,12 @@
 x_catch_errors_unwind (dummy)
      Lisp_Object dummy;
 {
+  xxxbuf[xxxidx++] = 'C';
+  xxxbuf[xxxidx] = 0;
+
+  if (! x_error_message)
+    fprintf (stderr, "%s\n", xxxbuf);
+
   Display *dpy = x_error_message->dpy;
   struct x_error_message_stack *tmp;


With these changes, I get a message like this:

  sCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCsCC

just before the crash (the message is only printed if x_error_message
is 0).  The length varies, but it is always a sequence of sC
(indicating a call to x_catch_errors followed by a call to
x_catch_errors_unwind) ending with CC, indicating that
x_catch_errors_unwind is being called twice, without an intervening
call to x_catch_errors.  Looking at the way these functions are used
in xterm.c, it is not at all obvious to me how that can happen.

I compiled Emacs with gcc 4.0.3 on an amd64 Debian system.  Here is
the output from gcc -v:

  Using built-in specs.
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release x86_64-linux-gnu
  Thread model: posix
  gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)

Here is the information from report-emacs-bug:

  In GNU Emacs 22.0.50.9 (x86_64-unknown-linux-gnu)
   of 2006-02-17 on segfault
  X server distributor `The X.Org Foundation', version 11.0.60900000
  configured using `configure '--prefix=/usr/local/cvs-emacs''

  Important settings:
    value of $LC_ALL: nil
    value of $LC_COLLATE: nil
    value of $LC_CTYPE: nil
    value of $LC_MESSAGES: nil
    value of $LC_MONETARY: nil
    value of $LC_NUMERIC: nil
    value of $LC_TIME: nil
    value of $LANG: nil
    locale-coding-system: nil
    default-enable-multibyte-characters: t

  Major mode: Lisp Interaction

  Minor modes in effect:
    tooltip-mode: t
    auto-compression-mode: t
    tool-bar-mode: t
    mouse-wheel-mode: t
    menu-bar-mode: t
    file-name-shadow-mode: t
    global-font-lock-mode: t
    font-lock-mode: t
    blink-cursor-mode: t
    unify-8859-on-encoding-mode: t
    utf-translate-cjk-mode: t
    line-number-mode: t

  Recent input:
  <help-echo> <help-echo> <help-echo> <help-echo> <escape> 
  x r e p o r t <tab> <return>

  Recent messages:
  (/usr/local/cvs-emacs/bin/emacs -q)
  For information about the GNU Project and its goals, type C-h C-p.
  Loading emacsbug...
  Loading regexp-opt...done
  Loading emacsbug...done

I'd be happy to try any other debugging.  I'm not subscribed to the
list.

Thanks,

jwe

             reply	other threads:[~2006-02-17  8:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17  8:04 John W. Eaton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-02-21 21:33 SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu) John W. Eaton
2006-02-23  2:39 ` Richard Stallman
2006-02-24  9:55 ` Richard Stallman
2006-02-25  7:45   ` John W. Eaton
2006-02-25 15:20     ` Chong Yidong
2006-02-25 15:36       ` Chong Yidong
2006-02-25 17:47         ` John W. Eaton
2006-02-25 23:29           ` Chong Yidong
2006-02-26  3:37             ` John W. Eaton
2006-02-27  8:58             ` Richard Stallman
2006-02-28  0:51               ` Chong Yidong
2006-03-05  0:59                 ` Richard Stallman
2006-02-26 16:00           ` Richard Stallman
2006-02-26 12:11         ` Richard Stallman
     [not found] <v9oe1hg44k.fsf@marauder.physik.uni-ulm.de>
2006-02-13  4:40 ` Richard M. Stallman
2006-02-13 14:04   ` Reiner Steib
2006-02-13 17:05     ` Stefan Monnier
2006-02-14  0:40       ` Richard M. Stallman
2006-02-17 14:27       ` Reiner Steib
2006-02-17 15:20         ` Reproducible crashes: dropping an URL (was: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)) Reiner Steib
2006-02-17 16:01           ` Reproducible crashes: dropping an URL Stefan Monnier
2006-02-20 14:59             ` SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu) (was: Reproducible crashes: dropping an URL) Reiner Steib
2006-02-20 15:04               ` SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu) Stefan Monnier
2006-02-20 20:05                 ` Reiner Steib
2006-02-21  4:39                   ` Chong Yidong
2006-02-22  5:23                     ` Richard M. Stallman
2006-02-21  5:30                 ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17397.33686.218699.659071@segfault.lan \
    --to=jwe@bevo.che.wisc.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).