Crash of Emacs 22.1

Crash of Emacs 22.1

[Jochen Luebbers]

Hello,

unfortunately my emacs crashed. I was not used to such things by emacs,
until I got this GNU Emacs 21.3.1 from RHEL 4.

At the behest of this news groupe I updated to GNU Emacs 22.1.1 at the
31th of october and every thins seems to be fine.

But today I got ie again. It was just, when I selected
"Postscript Print Buffer (B+W)" from the menu. (The printout was not
started.)

But this time I got a usable core-dump, I thought. But am I right?

Look at this, it seems to be the interessting part of the dump:

#18 <signal handler called>
#19 0x0812d0a9 in mem_delete (z=Variable "z" is not available.
) at alloc.c:3940
#20 0x0812d30e in lisp_free (block=0x9621708) at alloc.c:893
#21 0x08131386 in Fgarbage_collect () at alloc.c:6259
#22 0x0816c992 in Fbyte_code (bytestr=136141291, vector=136141308, maxdepth=48)
    at bytecode.c:724

Obviously the crash happened during a garbage collection. But at line
3940 of file alloc.c there is not routine "mem_delete".
There is "mem_delete_fixup"...

So it's no surprise when gdb says: z=Variable "z" is not available.

Seeking for advice: How can I help to fix things here?

Regards
    Jochen

-- 
  "Who desire to give up freedom in order to gain security
   will loose both in the end."

Re: Crash of Emacs 22.1

[Andreas Schwab]

Jochen Luebbers <jole@buerotiger.de> writes:

> Look at this, it seems to be the interessting part of the dump:
>
> #18 <signal handler called>
> #19 0x0812d0a9 in mem_delete (z=Variable "z" is not available.
> ) at alloc.c:3940
> #20 0x0812d30e in lisp_free (block=0x9621708) at alloc.c:893
> #21 0x08131386 in Fgarbage_collect () at alloc.c:6259
> #22 0x0816c992 in Fbyte_code (bytestr=136141291, vector=136141308, maxdepth=48)
>     at bytecode.c:724
>
> Obviously the crash happened during a garbage collection. But at line
> 3940 of file alloc.c there is not routine "mem_delete".
> There is "mem_delete_fixup"...

mem_delete_fixup is static, so it has been inlined into its sole caller.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Crash of Emacs 22.1

[Stefan Monnier]

> Look at this, it seems to be the interessting part of the dump:

> #18 <signal handler called>
> #19 0x0812d0a9 in mem_delete (z=Variable "z" is not available.
> ) at alloc.c:3940
> #20 0x0812d30e in lisp_free (block=0x9621708) at alloc.c:893
> #21 0x08131386 in Fgarbage_collect () at alloc.c:6259
> #22 0x0816c992 in Fbyte_code (bytestr=136141291, vector=136141308, maxdepth=48)
>     at bytecode.c:724

All this seems to indicate is that there's some memory corruption and
that the corruption caused a crash later on inside the GC (which is
usually where it happens since the GC looks at most of the memory).

Not much to go on.  The part of the stack trace just before entering the
GC might be a bit more enlightening, although I wouldn't hold my breath.

> Obviously the crash happened during a garbage collection. But at line
> 3940 of file alloc.c there is not routine "mem_delete".
> There is "mem_delete_fixup"...

> So it's no surprise when gdb says: z=Variable "z" is not available.

> Seeking for advice: How can I help to fix things here?

Fetch the Emacs-22.1 source code, so you can debug better, go to the
emacs/src directory (where there's a .gdbinit file which will provide
some extra commands) and then use `xbacktrace' which will give you
a Lisp-level backtrace (basically a more succint interpretation of
a subset of the C backtrace before the call to the GC).

Also, keep this core dump around, and try to reproduce the problem,
accumulating core dumps and stack backtraces over time, so we may be
able to find some pattern.  You may also want to run your Emacs
from within GDB so you'll always get a usable "core".
Also look at the emacs/etc/DEBUG file in the distribution.  Finally,
recompile without optimizations so GDB is a bit less confused by
variables that disappeared and things like that.


        Stefan

Re: Crash of Emacs 22.1

[Jochen Luebbers]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Not much to go on.  The part of the stack trace just before entering the
> GC might be a bit more enlightening, although I wouldn't hold my breath.

Here it is:

#22 0x0816c992 in Fbyte_code (bytestr=136141291, vector=136141308, 
    maxdepth=48) at bytecode.c:724
#23 0x081432fb in funcall_lambda (fun=136141228, nargs=4, 
    arg_vector=0xbff7d2b4) at eval.c:3184
#24 0x08143726 in Ffuncall (nargs=5, args=0xbff7d2b0) at eval.c:3054
#25 0x0816ba71 in Fbyte_code (bytestr=136150731, vector=136150748, 
    maxdepth=48) at bytecode.c:679
#26 0x081432fb in funcall_lambda (fun=136150676, nargs=2, 
    arg_vector=0xbff7d3f4) at eval.c:3184
#27 0x08143726 in Ffuncall (nargs=3, args=0xbff7d3f0) at eval.c:3054
#28 0x0816ba71 in Fbyte_code (bytestr=136150851, vector=136150868, 
    maxdepth=48) at bytecode.c:679
#29 0x081432fb in funcall_lambda (fun=136150788, nargs=3, 
    arg_vector=0xbff7d534) at eval.c:3184
#30 0x08143726 in Ffuncall (nargs=4, args=0xbff7d530) at eval.c:3054
#31 0x0816ba71 in Fbyte_code (bytestr=136154499, vector=136154524, 
    maxdepth=40) at bytecode.c:679
#32 0x08142e9f in Feval (form=136154485) at eval.c:2328
#33 0x08144f61 in internal_lisp_condition_case (var=137386185, 
    bodyform=136154485, handlers=136154605) at eval.c:1426
#34 0x0816be66 in Fbyte_code (bytestr=136154107, vector=136154124, 
    maxdepth=72) at bytecode.c:869
#35 0x081432fb in funcall_lambda (fun=136154068, nargs=1, 
    arg_vector=0xbff7d914) at eval.c:3184
#36 0x08143726 in Ffuncall (nargs=2, args=0xbff7d910) at eval.c:3054
#37 0x08144784 in call1 (fn=137542081, arg1=164329260) at eval.c:2782
#38 0x080cf3e6 in Fx_show_tip (string=164319123, frame=160999692, 
    parms=162084773, timeout=80, dx=40, dy=160) at xfns.c:4951
#39 0x0814381f in Ffuncall (nargs=7, args=0xbff7dad0) at eval.c:3028
#40 0x0816ba71 in Fbyte_code (bytestr=136614139, vector=136614164, 
    maxdepth=56) at bytecode.c:679
#41 0x08142e9f in Feval (form=136614125) at eval.c:2328
#42 0x08144f61 in internal_lisp_condition_case (var=137431641, 
    bodyform=136614125, handlers=136614269) at eval.c:1426
#43 0x0816be66 in Fbyte_code (bytestr=136614051, vector=136614068, 
    maxdepth=24) at bytecode.c:869
#44 0x081432fb in funcall_lambda (fun=136613996, nargs=2, 
    arg_vector=0xbff7de74) at eval.c:3184
#45 0x08143726 in Ffuncall (nargs=3, args=0xbff7de70) at eval.c:3054
#46 0x0816ba71 in Fbyte_code (bytestr=136615547, vector=136615564, 
    maxdepth=24) at bytecode.c:679
#47 0x081432fb in funcall_lambda (fun=136615508, nargs=1, 
    arg_vector=0xbff7e078) at eval.c:3184
#48 0x08143726 in Ffuncall (nargs=2, args=0xbff7e074) at eval.c:3054
#49 0x081448fe in run_hook_with_args (nargs=2, args=0xbff7e074, 
    cond=until_success) at eval.c:2656
#50 0x08143907 in Ffuncall (nargs=3, args=0xbff7e070) at eval.c:2978
#51 0x0816ba71 in Fbyte_code (bytestr=136613811, vector=136613828, 
    maxdepth=24) at bytecode.c:679
#52 0x081432fb in funcall_lambda (fun=136613772, nargs=1, 
    arg_vector=0xbff7e258) at eval.c:3184
#53 0x08143726 in Ffuncall (nargs=2, args=0xbff7e254) at eval.c:3054
#54 0x08144c4d in Fapply (nargs=2, args=0xbff7e254) at eval.c:2485
#55 0x08143907 in Ffuncall (nargs=3, args=0xbff7e250) at eval.c:2978
#56 0x0816ba71 in Fbyte_code (bytestr=136464363, vector=136464388, 
    maxdepth=32) at bytecode.c:679
#57 0x08142e9f in Feval (form=136464349) at eval.c:2328
#58 0x08144f61 in internal_lisp_condition_case (var=137386185, 
    bodyform=136464349, handlers=136464421) at eval.c:1426
#59 0x0816be66 in Fbyte_code (bytestr=136464219, vector=136464236, 
    maxdepth=40) at bytecode.c:869
#60 0x081432fb in funcall_lambda (fun=136464180, nargs=1, 
    arg_vector=0xbff7e614) at eval.c:3184
#61 0x08143726 in Ffuncall (nargs=2, args=0xbff7e610) at eval.c:3054
#62 0x08144784 in call1 (fn=137421609, arg1=164320988) at eval.c:2782
#63 0x080e6139 in timer_check (do_it_now=1) at keyboard.c:4575
#64 0x080e62da in readable_events (flags=1) at keyboard.c:3600
#65 0x080eb67b in get_input_pending (addr=0x82f31d8, flags=1)
    at keyboard.c:6722
#66 0x080eb74b in detect_input_pending_run_timers (do_display=1)
    at keyboard.c:10239
#67 0x081722ee in wait_reading_process_output (time_limit=30, microsecs=0, 
    read_kbd=-1, do_display=1, wait_for_cell=137386185, wait_proc=0x0, 
    just_wait_proc=0) at process.c:4697
#68 0x08058b2d in sit_for (timeout=240, reading=1, do_display=1)
    at dispnew.c:6579
#69 0x080ed00d in read_char (commandflag=1, nmaps=2, maps=0xbff7ed90, 
    prev_event=137386185, used_mouse_menu=0xbff7edd8, end_time=0x0)
    at keyboard.c:2904
#70 0x080ef2bc in read_key_sequence (keybuf=0xbff7eef0, bufsize=30, 
    prompt=137386185, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:9135
#71 0x080f0c2d in command_loop_1 () at keyboard.c:1618
#72 0x08141c36 in internal_condition_case (bfun=0x80f0a8c <command_loop_1>, 
    handlers=137431641, hfun=0x80ea134 <cmd_error>) at eval.c:1481
#73 0x080e4caa in command_loop_2 () at keyboard.c:1329
#74 0x08141915 in internal_catch (tag=137424825, 
    func=0x80e4c8c <command_loop_2>, arg=137386185) at eval.c:1222
#75 0x080e4ae9 in command_loop () at keyboard.c:1308
#76 0x080e4b84 in recursive_edit_1 () at keyboard.c:1006
#77 0x080e4c4e in Frecursive_edit () at keyboard.c:1067
#78 0x080e4005 in main (argc=1, argv=0xbff7f4f4) at emacs.c:1762


> Fetch the Emacs-22.1 source code, so you can debug better, go to the
> emacs/src directory (where there's a .gdbinit file which will provide
> some extra commands) and then use `xbacktrace' which will give you
> a Lisp-level backtrace (basically a more succint interpretation of
> a subset of the C backtrace before the call to the GC).

(gdb) xbacktrace
"set-face-attribute" (0x96ab091)
"face-spec-reset-face" (0x96ab091)
"face-spec-set" (0x96ab091)
"byte-code" (0x81d8d83)
"face-set-after-frame-default" (0x9cb772c)
"x-show-tip" (0x9cb4f93)
"byte-code" (0x82490fb)
"tooltip-show" (0x8543c93)
"tooltip-help-tips" (0x83058c9)
"run-hook-with-args-until-success" (0x854cfd1)
"tooltip-timeout" (0x83058c9)
"apply" (0x854d1b1)
"byte-code" (0x82247eb)
"timer-event-handler" (0x9cb56dc)
(gdb)


> Also, keep this core dump around, and try to reproduce the problem,
> accumulating core dumps and stack backtraces over time, so we may be
> able to find some pattern.

I'll keep my eyes open. But I'm not sure if there is any chance of
reproducing it actively. When I enter my office, I start my PC and open
emacs. And the last application closed before shutdown is: emacs.
So many things have happened (e.g. reading news) until the moment of the
crash.

>                             You may also want to run your Emacs
> from within GDB so you'll always get a usable "core".
> Also look at the emacs/etc/DEBUG file in the distribution.  Finally,
> recompile without optimizations so GDB is a bit less confused by
> variables that disappeared and things like that.

I'll check that. May be I can make some setup with a memory debugger.

Regards
    Jochen
-- 
  "Who desire to give up freedom in order to gain security
   will loose both in the end."                   (Benjamin Franklin)