crash in GC

crash in GC

[Sam Steingold]

GNU Emacs 21.2.50.9 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-05-20 on glip.premonitia.com

current CVS emacs crashed after a couple of days (=> it's not _that_
current :-) in GC:
 
(gdb) run --
Starting program: /usr/local/src/emacs/src/emacs --
   
Program received signal SIGSEGV, Segmentation fault.
allocate_string () at alloc.c:1332
1332      string_free_list = NEXT_FREE_LISP_STRING (s);
(gdb) where
#0  allocate_string () at alloc.c:1332
#1  0x081131d5 in make_uninit_multibyte_string (nchars=5, nbytes=5)
    at alloc.c:1873
#2  0x081131a4 in make_uninit_string (length=5) at alloc.c:1854
#3  0x0811306d in make_unibyte_string (contents=0xa684d35 "local", length=5)
    at alloc.c:1777
#4  0x080f63b8 in Ffile_name_nondirectory (filename=959205260) at fileio.c:495
#5  0x08127242 in Ffuncall (nargs=2, args=0xbfffd060) at eval.c:2721
#6  0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#7  0x0812777a in funcall_lambda (fun=1209787120, nargs=3, 
    arg_vector=0xbfffd18c) at eval.c:2908
#8  0x08127345 in Ffuncall (nargs=4, args=0xbfffd188) at eval.c:2778
#9  0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#10 0x0812777a in funcall_lambda (fun=1209787120, nargs=3, 
    arg_vector=0xbfffd2ac) at eval.c:2908
#11 0x08127345 in Ffuncall (nargs=4, args=0xbfffd2a8) at eval.c:2778
#12 0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#13 0x0812777a in funcall_lambda (fun=1209787120, nargs=3, 
    arg_vector=0xbfffd3cc) at eval.c:2908
#14 0x08127345 in Ffuncall (nargs=4, args=0xbfffd3c8) at eval.c:2778
#15 0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#16 0x0812777a in funcall_lambda (fun=1209787120, nargs=3, 
    arg_vector=0xbfffd4ec) at eval.c:2908
#17 0x08127345 in Ffuncall (nargs=4, args=0xbfffd4e8) at eval.c:2778
#18 0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#19 0x0812777a in funcall_lambda (fun=1209787120, nargs=3, 
    arg_vector=0xbfffd60c) at eval.c:2908
#20 0x08127345 in Ffuncall (nargs=4, args=0xbfffd608) at eval.c:2778
#21 0x0814dbb4 in Fbyte_code (bytestr=941351724, vector=1209787544, maxdepth=7)
    at bytecode.c:709
#22 0x0812777a in funcall_lambda (fun=1209787120, nargs=1, 
    arg_vector=0xbfffd728) at eval.c:2908
#23 0x08127345 in Ffuncall (nargs=2, args=0xbfffd724) at eval.c:2778
#24 0x0814dbb4 in Fbyte_code (bytestr=941358300, vector=1209794356, maxdepth=8)
    at bytecode.c:709
#25 0x0812777a in funcall_lambda (fun=1209793688, nargs=2, 
    arg_vector=0xbfffd844) at eval.c:2908
#26 0x08127345 in Ffuncall (nargs=3, args=0xbfffd840) at eval.c:2778
#27 0x0814dbb4 in Fbyte_code (bytestr=953198452, vector=1217927472, maxdepth=3)
    at bytecode.c:709
#28 0x0812777a in funcall_lambda (fun=1213189304, nargs=1, 
    arg_vector=0xbfffd958) at eval.c:2908
#29 0x08127345 in Ffuncall (nargs=2, args=0xbfffd954) at eval.c:2778
#30 0x0814dbb4 in Fbyte_code (bytestr=953810388, vector=1221775480, maxdepth=5)
    at bytecode.c:709
#31 0x0812777a in funcall_lambda (fun=1221775632, nargs=1, 
    arg_vector=0xbfffda74) at eval.c:2908
#32 0x08127345 in Ffuncall (nargs=2, args=0xbfffda70) at eval.c:2778
#33 0x0814dbb4 in Fbyte_code (bytestr=949445876, vector=1222076888, maxdepth=4)
    at bytecode.c:709
#34 0x0812777a in funcall_lambda (fun=1222077072, nargs=2, 
    arg_vector=0xbfffdb84) at eval.c:2908
#35 0x08127345 in Ffuncall (nargs=3, args=0xbfffdb80) at eval.c:2778
#36 0x0814dbb4 in Fbyte_code (bytestr=949446100, vector=1220678008, maxdepth=3)
---Type <return> to continue, or q <return> to quit---
    at bytecode.c:709
#37 0x0812777a in funcall_lambda (fun=1222076816, nargs=0, 
    arg_vector=0xbfffdc94) at eval.c:2908
#38 0x08127345 in Ffuncall (nargs=1, args=0xbfffdc90) at eval.c:2778
#39 0x0814dbb4 in Fbyte_code (bytestr=949446452, vector=1222548640, maxdepth=3)
    at bytecode.c:709
#40 0x0812777a in funcall_lambda (fun=1220677696, nargs=2, 
    arg_vector=0xbfffdda4) at eval.c:2908
#41 0x08127345 in Ffuncall (nargs=3, args=0xbfffdda0) at eval.c:2778
#42 0x08126c16 in Fapply (nargs=2, args=0xbfffde30) at eval.c:2228
#43 0x08126f57 in apply1 (fn=415925924, arg=1506205316) at eval.c:2484
#44 0x08153f08 in read_process_output_call (fun_and_args=1506205308)
    at process.c:4220
#45 0x081258d4 in internal_condition_case_1 (
    bfun=0x8153ef0 <read_process_output_call>, arg=1506205308, 
    handlers=405348836, hfun=0x8153f0c <read_process_output_error_handler>)
    at eval.c:1374
#46 0x08154299 in read_process_output (proc=1239015504, channel=10)
    at process.c:4423
#47 0x08153c0f in wait_reading_process_input (time_limit=-1, microsecs=0, 
    read_kbd=0, do_display=0) at process.c:4061
#48 0x08152c7d in Faccept_process_output (process=1227215048, timeout=1, 
    timeout_msecs=405348836) at process.c:3346
#49 0x08127272 in Ffuncall (nargs=3, args=0xbfffe620) at eval.c:2728
#50 0x0814dbb4 in Fbyte_code (bytestr=949035092, vector=1217472632, maxdepth=3)
    at bytecode.c:709
#51 0x0812777a in funcall_lambda (fun=1217472792, nargs=2, 
    arg_vector=0xbfffe734) at eval.c:2908
#52 0x08127345 in Ffuncall (nargs=3, args=0xbfffe730) at eval.c:2778
#53 0x0814dbb4 in Fbyte_code (bytestr=947887996, vector=1216249832, maxdepth=4)
    at bytecode.c:709
#54 0x0812777a in funcall_lambda (fun=1216324440, nargs=1, 
    arg_vector=0xbfffe844) at eval.c:2908
#55 0x08127345 in Ffuncall (nargs=2, args=0xbfffe840) at eval.c:2778
#56 0x0814dbb4 in Fbyte_code (bytestr=947888364, vector=1217299368, maxdepth=6)
    at bytecode.c:709
#57 0x0812777a in funcall_lambda (fun=1217304960, nargs=2, 
    arg_vector=0xbfffe964) at eval.c:2908
#58 0x08127345 in Ffuncall (nargs=3, args=0xbfffe960) at eval.c:2778
#59 0x0814dbb4 in Fbyte_code (bytestr=947888444, vector=1217304816, maxdepth=4)
    at bytecode.c:709
#60 0x0812777a in funcall_lambda (fun=1217303040, nargs=1, 
    arg_vector=0xbfffea74) at eval.c:2908
#61 0x08127345 in Ffuncall (nargs=2, args=0xbfffea70) at eval.c:2778
#62 0x0814dbb4 in Fbyte_code (bytestr=949069676, vector=1217506736, maxdepth=4)
    at bytecode.c:709
#63 0x0812777a in funcall_lambda (fun=1217506928, nargs=1, 
    arg_vector=0xbfffeb84) at eval.c:2908
#64 0x08127345 in Ffuncall (nargs=2, args=0xbfffeb80) at eval.c:2778
#65 0x0814dbb4 in Fbyte_code (bytestr=949090700, vector=1217530112, maxdepth=8)
    at bytecode.c:709
#66 0x0812777a in funcall_lambda (fun=1217530360, nargs=2, 
    arg_vector=0xbfffeca4) at eval.c:2908
#67 0x08127345 in Ffuncall (nargs=3, args=0xbfffeca0) at eval.c:2778
#68 0x0814dbb4 in Fbyte_code (bytestr=949090876, vector=1217148880, maxdepth=3)
    at bytecode.c:709
#69 0x0812777a in funcall_lambda (fun=1217530520, nargs=2, 
    arg_vector=0xbfffedb4) at eval.c:2908
#70 0x08127345 in Ffuncall (nargs=3, args=0xbfffedb0) at eval.c:2778
---Type <return> to continue, or q <return> to quit---
#71 0x0814dbb4 in Fbyte_code (bytestr=946645644, vector=1214997400, maxdepth=4)
    at bytecode.c:709
#72 0x0812777a in funcall_lambda (fun=1214997568, nargs=2, 
    arg_vector=0xbfffeec4) at eval.c:2908
#73 0x08127345 in Ffuncall (nargs=3, args=0xbfffeec0) at eval.c:2778
#74 0x0814dbb4 in Fbyte_code (bytestr=945643636, vector=1216236768, maxdepth=8)
    at bytecode.c:709
#75 0x0812777a in funcall_lambda (fun=1216237264, nargs=1, 
    arg_vector=0xbfffefe4) at eval.c:2908
#76 0x08127345 in Ffuncall (nargs=2, args=0xbfffefe0) at eval.c:2778
#77 0x0814dbb4 in Fbyte_code (bytestr=947647892, vector=1216714008, maxdepth=3)
    at bytecode.c:709
#78 0x0812777a in funcall_lambda (fun=1216714216, nargs=1, 
    arg_vector=0xbffff124) at eval.c:2908
#79 0x08127345 in Ffuncall (nargs=2, args=0xbffff120) at eval.c:2778
#80 0x08123fb7 in Fcall_interactively (function=409705516, 
    record_flag=405348836, keys=1223540536) at callint.c:787
#81 0x080dd546 in Fcommand_execute (cmd=409705516, record_flag=405348836, 
    keys=405348836, special=405348836) at keyboard.c:9338
#82 0x080d4304 in command_loop_1 () at keyboard.c:1662
#83 0x081257ea in internal_condition_case (bfun=0x80d3780 <command_loop_1>, 
    handlers=405445324, hfun=0x80d33c0 <cmd_error>) at eval.c:1334
#84 0x080d3662 in command_loop_2 () at keyboard.c:1254
#85 0x081253ab in internal_catch (tag=405406652, 
    func=0x80d3644 <command_loop_2>, arg=405348836) at eval.c:1094
#86 0x080d35f0 in command_loop () at keyboard.c:1233
#87 0x080d31a4 in recursive_edit_1 () at keyboard.c:959
#88 0x080d32bb in Frecursive_edit () at keyboard.c:1015
#89 0x080d2244 in main (argc=2, argv=0xbffff8c4, envp=0xbffff8d0)
    at emacs.c:1624
#90 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) p s
$1 = (struct Lisp_String *) 0xc8
(gdb) p *s
Cannot access memory at address 0xc8
(gdb) up
#1  0x081131d5 in make_uninit_multibyte_string (nchars=5, nbytes=5)
    at alloc.c:1873
1873      s = allocate_string ();
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
allocate_string () at alloc.c:1332
1332      string_free_list = NEXT_FREE_LISP_STRING (s);
(gdb) 


-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
"A pint of sweat will save a gallon of blood."          -- George S. Patton

Re: crash in GC

[Richard Stallman]

Could you investigate a little further and try to find the data that
is invalid or inconsistent?

Re: crash in GC

[Sam Steingold]

> * In message <200205240044.g4O0i9E01298@aztec.santafe.edu>
> * On the subject of "Re: crash in GC"
> * Sent on Thu, 23 May 2002 18:44:09 -0600 (MDT)
> * Honorable Richard Stallman <rms@gnu.org> writes:
>
> Could you investigate a little further and try to find the data that
> is invalid or inconsistent?

I am afraid not.  All I have is the backtrace.
(I restarted Emacs in the same gdb since I need it for other work.)


-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Daddy, what does "format disk c: complete" mean?

Re: crash in GC

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: 24 May 2002 10:19:28 -0400
> 
> > Could you investigate a little further and try to find the data that
> > is invalid or inconsistent?
> 
> I am afraid not.  All I have is the backtrace.
> (I restarted Emacs in the same gdb since I need it for other work.)

That is very unfortunate: it means that this bug report cannot be
pursued at all.  Please in the future try to leave the crashed session
running as long as the thread that discusses the crash is alive.  If
you can afford that resourcewise, that is.

Crashes inside GC generally mean that some memory corruption happened
earlier, but the backtrace doesn't say where and when.  It is
impossible to debug such problems armed with the backtrace alone; you
need to examine the relevant C and Lisp data structures, and you need
to check several hypotheses about the possible cause(s) of the
corruption.  You can't even start thinking about these issues without
knowing the extent of data structures that are corrupted, and without
access to the array that records the GC history.

Re: crash in GC

[Sam Steingold]

> * In message <E17BJT1-0002qA-00@fencepost.gnu.org>
> * On the subject of "Re: crash in GC"
> * Sent on Fri, 24 May 2002 14:07:07 -0400
> * Honorable Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: Sam Steingold <sds@gnu.org>
> > Date: 24 May 2002 10:19:28 -0400
> > 
> > > Could you investigate a little further and try to find the data that
> > > is invalid or inconsistent?
> > 
> > I am afraid not.  All I have is the backtrace.
> > (I restarted Emacs in the same gdb since I need it for other work.)
> 
> That is very unfortunate: it means that this bug report cannot be
> pursued at all.  Please in the future try to leave the crashed session
> running as long as the thread that discusses the crash is alive.

okay - what other options are there: is there a way to tell gdb to dump
core so that I can send it to someone interested in the matter?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Lisp suffers from being twenty or thirty years ahead of time.

Re: crash in GC

[Ken Raeburn]

Sam Steingold <sds@gnu.org> writes:
> okay - what other options are there: is there a way to tell gdb to dump
> core so that I can send it to someone interested in the matter?

You could use gdb's "call" command to invoke fork() or abort() in the
child process.

Though without your emacs image and symbol table, I'm skeptical that
the core file would be terribly useful.

Re: crash in GC

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: 24 May 2002 16:50:53 -0400
> 
> > That is very unfortunate: it means that this bug report cannot be
> > pursued at all.  Please in the future try to leave the crashed session
> > running as long as the thread that discusses the crash is alive.
> 
> okay - what other options are there: is there a way to tell gdb to dump
> core so that I can send it to someone interested in the matter?

No, it is useless to send the core file, since its information is only
meaningful on the system where it was produced (due to variability in
versions of the OS and system libraries).

Re: crash in GC

[Richard Stallman]

    okay - what other options are there: is there a way to tell gdb to dump
    core so that I can send it to someone interested in the matter?

It is not feasible to debug your core dump on another machine.
The executables will not be identical.

crash in GC

[Sam Steingold]

GNU Emacs 21.3.50.21 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-12-15 on loiso.podval.org

(gdb) run --
Starting program: /usr/local/src/emacs/src/emacs --

Program received signal SIGSEGV, Segmentation fault.
mem_find (start=0xa6fef5c) at alloc.c:2751
2751      while (start < p->start || start >= p->end)
(gdb) p start
$1 = (void *) 0xa6fef5c
(gdb) p p
$2 = (struct mem_node *) 0x0
(gdb) where
#0  mem_find (start=0xa6fef5c) at alloc.c:2751
#1  0x0811d144 in mark_maybe_object (obj=1517285212) at alloc.c:3336
#2  0x0811afd9 in mark_memory (start=0xbfffd240, end=0xbffff3dc)
    at alloc.c:3545
#3  0x0811b02c in mark_stack () at alloc.c:3781
#4  0x0811b557 in Fgarbage_collect () at alloc.c:4152
#5  0x0812f314 in Ffuncall (nargs=3, args=0xbfffd3d0) at eval.c:2681
#6  0x0812eb0e in Fapply (nargs=2, args=0xbfffd460) at eval.c:2248
#7  0x0812eefd in apply1 (fn=412461620, arg=1494465156) at eval.c:2504
#8  0x0815d478 in read_process_output_call (fun_and_args=1494465132)
    at process.c:4293
#9  0x0812d810 in internal_condition_case_1 (
    bfun=0x815d460 <read_process_output_call>, arg=1494465132, 
    handlers=405471332, hfun=0x815d47c <read_process_output_error_handler>)
    at eval.c:1392
#10 0x0815d6f9 in read_process_output (proc=1259168120, channel=1259168120)
    at process.c:4496
#11 0x0815ccbe in wait_reading_process_input (time_limit=-1, microsecs=0, 
    read_kbd=0, do_display=0) at process.c:4134
#12 0x0815c0ff in Faccept_process_output (process=1259168120, timeout=16, 
    timeout_msecs=0) at process.c:3415
#13 0x0812f22e in Ffuncall (nargs=3, args=0xbfffdbf0) at eval.c:2741
#14 0x08156d54 in Fbyte_code (bytestr=412458708, vector=2, 
    maxdepth=-1073750944) at bytecode.c:709
#15 0x0812f51f in funcall_lambda (fun=1217666352, nargs=2, 
    arg_vector=0xbfffdd74) at eval.c:2928
#16 0x0812f107 in Ffuncall (nargs=3, args=0xbfffdd70) at eval.c:2798
#17 0x08156d54 in Fbyte_code (bytestr=405582564, vector=2, 
    maxdepth=-1073750672) at bytecode.c:709
#18 0x0812f51f in funcall_lambda (fun=1217117720, nargs=1, 
    arg_vector=0xbfffde84) at eval.c:2928
#19 0x0812f107 in Ffuncall (nargs=2, args=0xbfffde80) at eval.c:2798
#20 0x08156d54 in Fbyte_code (bytestr=411191172, vector=1, 
    maxdepth=-1073750400) at bytecode.c:709
#21 0x0812f51f in funcall_lambda (fun=1217447328, nargs=2, 
    arg_vector=0xbfffdfa4) at eval.c:2928
#22 0x0812f107 in Ffuncall (nargs=3, args=0xbfffdfa0) at eval.c:2798
#23 0x08156d54 in Fbyte_code (bytestr=406274076, vector=2, 
    maxdepth=-1073750112) at bytecode.c:709
#24 0x0812f51f in funcall_lambda (fun=1217583280, nargs=2, 
    arg_vector=0xbfffe0b4) at eval.c:2928
#25 0x0812f107 in Ffuncall (nargs=3, args=0xbfffe0b0) at eval.c:2798
#26 0x08156d54 in Fbyte_code (bytestr=406274076, vector=2, 
    maxdepth=-1073749840) at bytecode.c:709
#27 0x0812f51f in funcall_lambda (fun=1217290864, nargs=2, 
    arg_vector=0xbfffe1d4) at eval.c:2928
#28 0x0812f107 in Ffuncall (nargs=3, args=0xbfffe1d0) at eval.c:2798
#29 0x08156d54 in Fbyte_code (bytestr=405875452, vector=2, 
    maxdepth=-1073749552) at bytecode.c:709
#30 0x0812f51f in funcall_lambda (fun=1217301688, nargs=2, 
    arg_vector=0xbfffe2f4) at eval.c:2928
#31 0x0812f107 in Ffuncall (nargs=3, args=0xbfffe2f0) at eval.c:2798
---Type <return> to continue, or q <return> to quit---
#32 0x08156d54 in Fbyte_code (bytestr=410750900, vector=2, 
    maxdepth=-1073749264) at bytecode.c:709
#33 0x0812f51f in funcall_lambda (fun=1216588808, nargs=2, 
    arg_vector=0xbfffe404) at eval.c:2928
#34 0x0812f107 in Ffuncall (nargs=3, args=0xbfffe400) at eval.c:2798
#35 0x08156d54 in Fbyte_code (bytestr=405579572, vector=2, 
    maxdepth=-1073748992) at bytecode.c:709
#36 0x0812f51f in funcall_lambda (fun=1216608640, nargs=2, 
    arg_vector=0xbfffe524) at eval.c:2928
#37 0x0812f107 in Ffuncall (nargs=3, args=0xbfffe520) at eval.c:2798
#38 0x08156d54 in Fbyte_code (bytestr=405579572, vector=2, 
    maxdepth=-1073748704) at bytecode.c:709
#39 0x0812f51f in funcall_lambda (fun=1216183264, nargs=1, 
    arg_vector=0xbfffe644) at eval.c:2928
#40 0x0812f107 in Ffuncall (nargs=2, args=0xbfffe640) at eval.c:2798
#41 0x08156d54 in Fbyte_code (bytestr=408621940, vector=1, 
    maxdepth=-1073748416) at bytecode.c:709
#42 0x0812f51f in funcall_lambda (fun=1216172928, nargs=3, 
    arg_vector=0xbfffe764) at eval.c:2928
#43 0x0812f107 in Ffuncall (nargs=4, args=0xbfffe760) at eval.c:2798
#44 0x08156d54 in Fbyte_code (bytestr=411108948, vector=3, 
    maxdepth=-1073748128) at bytecode.c:709
#45 0x0812e87a in Feval (form=136774776) at eval.c:2096
#46 0x0812c3b1 in Fprogn (args=0) at eval.c:424
#47 0x0812fcb7 in unbind_to (count=15, value=405471332) at eval.c:3097
#48 0x08156da6 in Fbyte_code (bytestr=411108948, vector=3, 
    maxdepth=-1073747696) at bytecode.c:730
#49 0x0812f51f in funcall_lambda (fun=1216709400, nargs=3, 
    arg_vector=0xbfffea24) at eval.c:2928
#50 0x0812f107 in Ffuncall (nargs=4, args=0xbfffea20) at eval.c:2798
#51 0x08156d54 in Fbyte_code (bytestr=411108924, vector=3, 
    maxdepth=-1073747424) at bytecode.c:709
#52 0x0812f51f in funcall_lambda (fun=1216424088, nargs=3, 
    arg_vector=0xbfffeb34) at eval.c:2928
#53 0x0812f107 in Ffuncall (nargs=4, args=0xbfffeb30) at eval.c:2798
#54 0x08156d54 in Fbyte_code (bytestr=411108924, vector=3, 
    maxdepth=-1073747152) at bytecode.c:709
#55 0x0812f51f in funcall_lambda (fun=1216707888, nargs=2, 
    arg_vector=0xbfffec44) at eval.c:2928
#56 0x0812f107 in Ffuncall (nargs=3, args=0xbfffec40) at eval.c:2798
#57 0x08156d54 in Fbyte_code (bytestr=411108924, vector=2, 
    maxdepth=-1073746880) at bytecode.c:709
#58 0x0812f51f in funcall_lambda (fun=1216423448, nargs=0, 
    arg_vector=0xbfffed54) at eval.c:2928
#59 0x0812f107 in Ffuncall (nargs=1, args=0xbfffed50) at eval.c:2798
#60 0x08156d54 in Fbyte_code (bytestr=408565300, vector=0, 
    maxdepth=-1073746608) at bytecode.c:709
#61 0x0812f51f in funcall_lambda (fun=1214571896, nargs=1, 
    arg_vector=0xbfffee94) at eval.c:2928
#62 0x0812f107 in Ffuncall (nargs=2, args=0xbfffee90) at eval.c:2798
#63 0x0812af51 in Fcall_interactively (function=405471332, 
    record_flag=405471332, keys=1225264840) at callint.c:819
---Type <return> to continue, or q <return> to quit---
#64 0x080e147a in Fcommand_execute (cmd=409258084, record_flag=405471332, 
    keys=405471332, special=405471332) at keyboard.c:9536
#65 0x080d6d8a in command_loop_1 () at keyboard.c:1690
#66 0x0812d71e in internal_condition_case (bfun=0x80d6a60 <command_loop_1>, 
    handlers=405567940, hfun=0x80d665c <cmd_error>) at eval.c:1352
#67 0x080d6946 in command_loop_2 () at keyboard.c:1274
#68 0x0812d2d9 in internal_catch (tag=0, func=0x80d6928 <command_loop_2>, 
    arg=405471332) at eval.c:1112
#69 0x080d68fc in command_loop () at keyboard.c:1253
#70 0x080d643b in recursive_edit_1 () at keyboard.c:969
#71 0x080d6548 in Frecursive_edit () at keyboard.c:1025
#72 0x080d4ea3 in main (argc=2, argv=0xbffff654) at emacs.c:1647
#73 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) up
#1  0x0811d144 in mark_maybe_object (obj=1517285212) at alloc.c:3336
3336      struct mem_node *m = mem_find (po);
(gdb) p po
$3 = (void *) 0xa6fef5c
(gdb) p *po
Attempt to dereference a generic pointer.
(gdb) down
#0  mem_find (start=0xa6fef5c) at alloc.c:2751
2751      while (start < p->start || start >= p->end)
(gdb) list
2746      /* Make the search always successful to speed up the loop below.  */
2747      mem_z.start = start;
2748      mem_z.end = (char *) start + 1;
2749
2750      p = mem_root;
2751      while (start < p->start || start >= p->end)
2752        p = start < p->start ? p->left : p->right;
2753      return p;
2754    }
2755
(gdb) p mem_root
$4 = (struct mem_node *) 0x843c8e0
(gdb) p *mem_root
$5 = {
  left = 0x83c0968, 
  right = 0x8c33c58, 
  parent = 0x0, 
  start = 0x847eb18, 
  end = 0x847ef14, 
  color = MEM_BLACK, 
  type = MEM_TYPE_CONS
}
(gdb) p p
$6 = (struct mem_node *) 0x0
(gdb) p *mem_root->lift
There is no member named lift.
(gdb) p *mem_root->left
$7 = {
  left = 0x83ad420, 
  right = 0x83d6bd8, 
  parent = 0x843c8e0, 
  start = 0x83c0948, 
  end = 0x83c0964, 
  color = MEM_BLACK, 
  type = MEM_TYPE_VECTOR
}
(gdb) p *mem_root->left->right
$8 = {
  left = 0x83cbaa0, 
  right = 0x83e0d50, 
  parent = 0x83c0968, 
  start = 0x83d6bb8, 
  end = 0x83d6bd4, 
  color = MEM_BLACK, 
  type = MEM_TYPE_VECTOR
}
(gdb) p *mem_root->left->left
$9 = {
  left = 0x83a4658, 
  right = 0x83b73a0, 
  parent = 0x83c0968, 
  start = 0x83ad400, 
  end = 0x83ad41c, 
  color = MEM_BLACK, 
  type = MEM_TYPE_VECTOR
}
(gdb) p *mem_root->right->right
$10 = {
  left = 0x8cdceb8, 
  right = 0x8e7b320, 
  parent = 0x8c33c58, 
  start = 0x8d9ab00, 
  end = 0x8d9aef4, 
  color = MEM_BLACK, 
  type = MEM_TYPE_SYMBOL
}
(gdb) p *mem_root->right->left
$11 = {
  left = 0x8639d88, 
  right = 0x8bea0c0, 
  parent = 0x8c33c58, 
  start = 0x88af258, 
  end = 0x88af274, 
  color = MEM_BLACK, 
  type = MEM_TYPE_VECTOR
}


-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Warning! Dates in calendar are closer than they appear!

Re: crash in GC

[Richard Stallman]

The first step of debugging this is to track the path
that mem_find would have taken thru the mem_root data structure
and see if you can find anything invalid in that data structure.

I suspect you will find that a `right' or `left' pointer is NULL.
That shouldn't ever happen; in a leaf, these pointers should be
MEM_NIL which is not NULL.  At least, that's what I concluded
from reading the code.

I will install this change to document the data structure more
clearly.

*** alloc.c.~1.282.~	Thu Nov 14 21:41:01 2002
--- alloc.c	Thu Dec 19 11:48:25 2002
***************
*** 341,347 ****
  
  struct mem_node
  {
!   struct mem_node *left, *right, *parent;
  
    /* Start and end of allocated region.  */
    void *start, *end;
--- 341,352 ----
  
  struct mem_node
  {
!   /* Children of this node.  These pointers are never NULL.  When there
!      is no child, the value is MEM_NIL, which points to a dummy node.  */
!   struct mem_node *left, *right;
! 
!   /* The parent of this node.  In the root node, this is NULL.  */
!   struct mem_node *parent;
  
    /* Start and end of allocated region.  */
    void *start, *end;