Segmentation fault: Display *dpy = x_error_message->dpy;

Segmentation fault: Display *dpy = x_error_message->dpy;

[Luc Teirlinck]

Using `emacs-22.0.50 -Q -nbc' and _not_ running under gdb, I get
segmentation faults about once in every five to seven times I start
Emacs (always at startup, never later).  This is, for some strange
reason, exceedingly hard to reproduce while running under gdb, but
after countless tries I was able to make this happen twice, twice with
the error being due to

Display *dpy = x_error_message->dpy;

Apparently, there is no memory allocated for x_error_message->dpy;

This is on GNU/Linux.

===File ~/bt================================================
(gdb) run -Q -nbc
Starting program: /home/teirllm/emacscvsdir/emacs/src/emacs-22.0.50.1 -Q -nbc

Program received signal SIGSEGV, Segmentation fault.
0x080bafe0 in x_catch_errors_unwind (dummy=137383961) at xterm.c:7543
7543	  Display *dpy = x_error_message->dpy;
(gdb) bt
#0  0x080bafe0 in x_catch_errors_unwind (dummy=137383961) at xterm.c:7543
#1  0x081342f7 in unbind_to (count=29, value=137383961) at eval.c:3233
#2  0x08158fc9 in Fbyte_code (bytestr=136211651, vector=136211740, maxdepth=32)
    at bytecode.c:905
#3  0x08133ea7 in funcall_lambda (fun=136211588, nargs=3, 
    arg_vector=0xbfffea74) at eval.c:3066
#4  0x08133a79 in Ffuncall (nargs=4, args=0xbfffea70) at eval.c:2934
#5  0x081588e8 in Fbyte_code (bytestr=136211915, vector=136211948, maxdepth=40)
    at bytecode.c:694
#6  0x08133ea7 in funcall_lambda (fun=136211852, nargs=3, 
    arg_vector=0xbfffeb94) at eval.c:3066
#7  0x08133a79 in Ffuncall (nargs=4, args=0xbfffeb90) at eval.c:2934
#8  0x081588e8 in Fbyte_code (bytestr=136214443, vector=136214788, maxdepth=48)
    at bytecode.c:694
#9  0x08133ea7 in funcall_lambda (fun=136214404, nargs=1, 
    arg_vector=0xbfffecb4) at eval.c:3066
#10 0x08133a79 in Ffuncall (nargs=2, args=0xbfffecb0) at eval.c:2934
#11 0x081588e8 in Fbyte_code (bytestr=136216107, vector=136216188, maxdepth=40)
    at bytecode.c:694
#12 0x08133ea7 in funcall_lambda (fun=136216060, nargs=1, 
    arg_vector=0xbfffedd4) at eval.c:3066
#13 0x08133a79 in Ffuncall (nargs=2, args=0xbfffedd0) at eval.c:2934
#14 0x081588e8 in Fbyte_code (bytestr=136641539, vector=136641580, maxdepth=24)
    at bytecode.c:694
#15 0x08133ea7 in funcall_lambda (fun=136641492, nargs=1, 
    arg_vector=0xbfffeee4) at eval.c:3066
#16 0x08133a79 in Ffuncall (nargs=2, args=0xbfffeee0) at eval.c:2934
#17 0x081588e8 in Fbyte_code (bytestr=136637403, vector=136637508, maxdepth=32)
    at bytecode.c:694
#18 0x08133ea7 in funcall_lambda (fun=136637372, nargs=0, 
    arg_vector=0xbfffeff4) at eval.c:3066
#19 0x08133a79 in Ffuncall (nargs=1, args=0xbfffeff0) at eval.c:2934
#20 0x081588e8 in Fbyte_code (bytestr=136830787, vector=136832372, maxdepth=56)
    at bytecode.c:694
#21 0x08133ea7 in funcall_lambda (fun=136830764, nargs=0, 
    arg_vector=0xbffff114) at eval.c:3066
#22 0x08133a79 in Ffuncall (nargs=1, args=0xbffff110) at eval.c:2934
#23 0x081588e8 in Fbyte_code (bytestr=136825211, vector=136825372, maxdepth=48)
    at bytecode.c:694
#24 0x08133ea7 in funcall_lambda (fun=136825188, nargs=0, 
    arg_vector=0xbffff1d0) at eval.c:3066
#25 0x08133bb6 in apply_lambda (fun=136825188, args=137383961, eval_flag=1)
    at eval.c:2988
#26 0x08133127 in Feval (form=138955717) at eval.c:2277
#27 0x080dab55 in top_level_2 () at keyboard.c:1337
#28 0x08131fc6 in internal_condition_case (bfun=0x80dab44 <top_level_2>, 
    handlers=137428585, hfun=0x80da850 <cmd_error>) at eval.c:1465
#29 0x080dab81 in top_level_1 () at keyboard.c:1345
#30 0x08131b3b in internal_catch (tag=137424817, func=0x80dab58 <top_level_1>, 
    arg=137383961) at eval.c:1211
#31 0x080daaa7 in command_loop () at keyboard.c:1302
#32 0x080da60f in recursive_edit_1 () at keyboard.c:1000
#33 0x080da737 in Frecursive_edit () at keyboard.c:1061
#34 0x080d95b7 in main (argc=3, argv=0xbffff844) at emacs.c:1789
#35 0x40317627 in __libc_start_main (main=0x80d8890 <main>, argc=3, 
    ubp_av=0xbffff844, init=0x804e1f8 <_init>, fini=0x8176704 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff83c)
    at ../sysdeps/generic/libc-start.c:129

Lisp Backtrace:
"face-attr-match-p"
"face-spec-match-p"
"frame-set-background-mode"
"x-create-frame-with-faces"
"make-frame"
"frame-initialize"
"command-line"
"normal-top-level"

(gdb) p x_error_message->dpy
Cannot access memory at address 0xc8

============================================================

Segmentation fault: Display *dpy = x_error_message->dpy;

[Luc Teirlinck]

>From my previous message:

   Apparently, there is no memory allocated for x_error_message->dpy;

Well, the actual problem is that x_error_message == 0.

But after more careful checking, I see that this problem has already
been reported several times, the first time more than 15 days ago.

The delays for emacs-devel are currently so huge that maybe somebody
will have solved the problem before my messages on this actually arrive.

Sincerely,

Luc.

Re: Segmentation fault: Display *dpy = x_error_message->dpy;

[Chong Yidong]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Using `emacs-22.0.50 -Q -nbc' and _not_ running under gdb, I get
> segmentation faults about once in every five to seven times I start
> Emacs
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x080bafe0 in x_catch_errors_unwind (dummy=137383961) at xterm.c:7543

There is no longer an x_catch_errors_unwind function in xterm.c, so
you must be using an old version.  Can you try with the latest sources
and see if the crashes still happen?  I recently checked in some
changes recently to fix this bug (see the thread "SEGV in
x_catch_errors_unwind" in emacs-devel).

Re: Segmentation fault: Display *dpy = x_error_message->dpy;

[Luc Teirlinck]

Chong Yidong wrote:

   There is no longer an x_catch_errors_unwind function in xterm.c, so
   you must be using an old version.  Can you try with the latest sources
   and see if the crashes still happen?  I recently checked in some
   changes recently to fix this bug (see the thread "SEGV in
   x_catch_errors_unwind" in emacs-devel).

If you look at the date on my message you will see that it was sent on
Thursday Feb 23, six days ago.  The problem no longer occurs now.

Sincerely,

Luc.