cvs head crash in GC

cvs head crash in GC

[Sam Steingold]

GNU Emacs 21.3.50.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-03-31 on loiso.podval.org

Program received signal SIGSEGV, Segmentation fault.
0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
(gdb) where
#0  0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
#1  0x0804feee in safe_bcopy (from=0x99390cc "\2649o\b", 
    to=0x99b4458 "\324y\316\bnnimap+mail.podval.org:.imap/lisp/misc", 
    size=504716) at dispnew.c:484
#2  0x0811c7e1 in compact_small_strings () at alloc.c:1641
#3  0x0811f4b3 in gc_sweep () at alloc.c:5069
#4  0x0811e4e4 in Fgarbage_collect () at alloc.c:4302
#5  0x08132254 in Ffuncall (nargs=1, args=0xbfffcbec) at eval.c:2680
#6  0x08131c92 in run_hook_with_args (nargs=1, args=0xbfffcbec, 
    cond=until_failure) at eval.c:2410
#7  0x08131baf in Frun_hook_with_args_until_failure (nargs=1, args=0xbfffcbec)
    at eval.c:2341
#8  0x080eea2e in Fkill_buffer (buffer=880) at buffer.c:1316
#9  0x0813216e in Ffuncall (nargs=2, args=0xbfffcc94) at eval.c:2740
#10 0x0815a144 in Fbyte_code (bytestr=412605412, vector=1, 
    maxdepth=-1073754992) at bytecode.c:709
#11 0x081317ba in Feval (form=136789944) at eval.c:2095
#12 0x0812f2f9 in Fprogn (args=504716) at eval.c:425
#13 0x08132bf7 in unbind_to (count=53, value=405486764) at eval.c:3096
#14 0x0815a196 in Fbyte_code (bytestr=412390308, vector=4, 
    maxdepth=-1073754560) at bytecode.c:730
#15 0x0813245f in funcall_lambda (fun=1217542192, nargs=2, 
    arg_vector=0xbfffcef0) at eval.c:2927
#16 0x0813232e in apply_lambda (fun=1217542192, args=405486812, eval_flag=1)
    at eval.c:2849
#17 0x0813161c in Feval (form=1217542192) at eval.c:2153
#18 0x08130554 in Fcondition_case (args=405486764) at eval.c:1298
#19 0x0815ad51 in Fbyte_code (bytestr=405596684, vector=143, 
    maxdepth=-1073753760) at bytecode.c:891
#20 0x0813245f in funcall_lambda (fun=1217442368, nargs=3, 
    arg_vector=0xbfffd278) at eval.c:2927
#21 0x08132047 in Ffuncall (nargs=4, args=0xbfffd274) at eval.c:2797
#22 0x0815a144 in Fbyte_code (bytestr=412423796, vector=3, 
    maxdepth=-1073753484) at bytecode.c:709
#23 0x0813245f in funcall_lambda (fun=1217763352, nargs=2, 
    arg_vector=0xbfffd394) at eval.c:2927
#24 0x08132047 in Ffuncall (nargs=3, args=0xbfffd390) at eval.c:2797
#25 0x0815a144 in Fbyte_code (bytestr=410861564, vector=2, 
    maxdepth=-1073753200) at bytecode.c:709
#26 0x0813245f in funcall_lambda (fun=1216086920, nargs=2, 
    arg_vector=0xbfffd4a4) at eval.c:2927
#27 0x08132047 in Ffuncall (nargs=3, args=0xbfffd4a0) at eval.c:2797
#28 0x0815a144 in Fbyte_code (bytestr=405804660, vector=2, 
    maxdepth=-1073752928) at bytecode.c:709
#29 0x0813245f in funcall_lambda (fun=1216464320, nargs=2, 
    arg_vector=0xbfffd5c4) at eval.c:2927
#30 0x08132047 in Ffuncall (nargs=3, args=0xbfffd5c0) at eval.c:2797
#31 0x0815a144 in Fbyte_code (bytestr=405804660, vector=2, 
    maxdepth=-1073752640) at bytecode.c:709
#32 0x0813245f in funcall_lambda (fun=1216573016, nargs=1, 
    arg_vector=0xbfffd6e4) at eval.c:2927
#33 0x08132047 in Ffuncall (nargs=2, args=0xbfffd6e0) at eval.c:2797
#34 0x0815a144 in Fbyte_code (bytestr=408556700, vector=1, 
    maxdepth=-1073752352) at bytecode.c:709
#35 0x0813245f in funcall_lambda (fun=1216589568, nargs=3, 
    arg_vector=0xbfffd804) at eval.c:2927
#36 0x08132047 in Ffuncall (nargs=4, args=0xbfffd800) at eval.c:2797
#37 0x0815a144 in Fbyte_code (bytestr=411146028, vector=3, 
    maxdepth=-1073752064) at bytecode.c:709
---Type <return> to continue, or q <return> to quit---
#38 0x081317ba in Feval (form=136789944) at eval.c:2095
#39 0x0812f2f9 in Fprogn (args=504716) at eval.c:425
#40 0x08132bf7 in unbind_to (count=16, value=405486764) at eval.c:3096
#41 0x0815a196 in Fbyte_code (bytestr=411146028, vector=3, 
    maxdepth=-1073751632) at bytecode.c:730
#42 0x0813245f in funcall_lambda (fun=1216594992, nargs=3, 
    arg_vector=0xbfffdac4) at eval.c:2927
#43 0x08132047 in Ffuncall (nargs=4, args=0xbfffdac0) at eval.c:2797
#44 0x0815a144 in Fbyte_code (bytestr=411146004, vector=3, 
    maxdepth=-1073751360) at bytecode.c:709
#45 0x0813245f in funcall_lambda (fun=1215157968, nargs=3, 
    arg_vector=0xbfffdbd4) at eval.c:2927
#46 0x08132047 in Ffuncall (nargs=4, args=0xbfffdbd0) at eval.c:2797
#47 0x0815a144 in Fbyte_code (bytestr=411146004, vector=3, 
    maxdepth=-1073751088) at bytecode.c:709
#48 0x0813245f in funcall_lambda (fun=1216590816, nargs=2, 
    arg_vector=0xbfffdce4) at eval.c:2927
#49 0x08132047 in Ffuncall (nargs=3, args=0xbfffdce0) at eval.c:2797
#50 0x0815a144 in Fbyte_code (bytestr=411146004, vector=2, 
    maxdepth=-1073750816) at bytecode.c:709
#51 0x0813245f in funcall_lambda (fun=1213424928, nargs=0, 
    arg_vector=0xbfffddf4) at eval.c:2927
#52 0x08132047 in Ffuncall (nargs=1, args=0xbfffddf0) at eval.c:2797
#53 0x0815a144 in Fbyte_code (bytestr=408598156, vector=0, 
    maxdepth=-1073750544) at bytecode.c:709
#54 0x0813245f in funcall_lambda (fun=1213508128, nargs=1, 
    arg_vector=0xbfffdf34) at eval.c:2927
#55 0x08132047 in Ffuncall (nargs=2, args=0xbfffdf30) at eval.c:2797
#56 0x0812e0d0 in Fcall_interactively (function=408773500, 
    record_flag=405486764, keys=1230728024) at callint.c:846
#57 0x080e3e06 in Fcommand_execute (cmd=-1738710148, record_flag=405486764, 
    keys=405486764, special=405486764) at keyboard.c:9618
#58 0x080d958f in command_loop_1 () at keyboard.c:1753
#59 0x08130656 in internal_condition_case (bfun=0x80d9240 <command_loop_1>, 
    handlers=405583372, hfun=0x80d8e30 <cmd_error>) at eval.c:1351
#60 0x080d911a in command_loop_2 () at keyboard.c:1290
#61 0x081301f9 in internal_catch (tag=504716, func=0x80d90fc <command_loop_2>, 
    arg=405486764) at eval.c:1112
#62 0x080d90d0 in command_loop () at keyboard.c:1269
#63 0x080d8c0c in recursive_edit_1 () at keyboard.c:985
#64 0x080d8d1c in Frecursive_edit () at keyboard.c:1041
#65 0x080d7677 in main (argc=2, argv=0xbfffe6d4) at emacs.c:1659
#66 0x420154a0 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) up
#1  0x0804feee in safe_bcopy (from=0x99390cc "\2649o\b", 
    to=0x99b4458 "\324y\316\bnnimap+mail.podval.org:.imap/lisp/misc", 
    size=504716) at dispnew.c:484
484                   bcopy (endf, endt, to - from);
(gdb) list
479                   endf -= (to - from);
480
481                   if (endt < to)
482                     break;
483
484                   bcopy (endf, endt, to - from);
485                 }
486
487               /* If SIZE wasn't a multiple of TO - FROM, there will be a
488                  little left over.  The amount left over is (endt + (to -
(gdb) p endf
No symbol "endf" in current context.
(gdb) p endt
No symbol "endt" in current context.
(gdb) p to
$1 = 0x99b4458 "\324y\316\bnnimap+mail.podval.org:.imap/lisp/misc"
(gdb) p from
$2 = 0x99390cc "\2649o\b"
(gdb) up
#2  0x0811c7e1 in compact_small_strings () at alloc.c:1641
1641                      safe_bcopy ((char *) from, (char *) to, nbytes);
(gdb) p from
$3 = (struct sdata *) 0x1ece3
(gdb) p *from
Cannot access memory at address 0x1ece3
(gdb) p to
$4 = (struct sdata *) 0x99b4458
(gdb) p *to
$5 = {
  string = 0x8ce79d4, 
  u = {
    data = "n", 
    nbytes = 1835626094
  }
}
(gdb) p nbytes
No symbol "nbytes" in current context.
(gdb) p nbytes
No symbol "nbytes" in current context.
(gdb) up
#3  0x0811f4b3 in gc_sweep () at alloc.c:5069
5069      sweep_strings ();
(gdb) list
5064    {
5065      /* Remove or mark entries in weak hash tables.
5066         This must be done before any object is unmarked.  */
5067      sweep_weak_hash_tables ();
5068
5069      sweep_strings ();
5070    #ifdef GC_CHECK_STRING_BYTES
5071      if (!noninteractive)
5072        check_string_bytes (1);
5073    #endif
(gdb) down
#2  0x0811c7e1 in compact_small_strings () at alloc.c:1641
1641                      safe_bcopy ((char *) from, (char *) to, nbytes);
(gdb) list
1636
1637                  /* Copy, and update the string's `data' pointer.  */
1638                  if (from != to)
1639                    {
1640                      xassert (tb != b || to <= from);
1641                      safe_bcopy ((char *) from, (char *) to, nbytes);
1642                      to->string->data = SDATA_DATA (to);
1643                    }
1644
1645                  /* Advance past the sdata we copied to.  */
(gdb) p tb
$6 = (struct sblock *) 0x99b4450
(gdb) p *tb
$7 = {
  next = 0x9961548, 
  next_free = 0x99b644c, 
  first_data = {
    string = 0x8ce79d4, 
    u = {
      data = "n", 
      nbytes = 1835626094
    }
  }
}
(gdb) p b
$8 = (struct sblock *) 0x9937698
(gdb) p *b
$9 = {
  next = 0x9939698, 
  next_free = 0x9939684, 
  first_data = {
    string = 0x8d68af4, 
    u = {
      data = "s", 
      nbytes = 778268531
    }
  }
}
(gdb) p to
$10 = (struct sdata *) 0x99b4458
(gdb) p *to
$11 = {
  string = 0x8ce79d4, 
  u = {
    data = "n", 
    nbytes = 1835626094
  }


-- 
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>
The only time you have too much fuel is when you're on fire.

Re: cvs head crash in GC

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: 31 Mar 2003 19:24:56 -0500
> 
> GNU Emacs 21.3.50.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2003-03-31 on loiso.podval.org

Someone please change the CVS version to say 21.4.50, now that Emacs
21.3 has been released.

TIA

Re: cvs head crash in GC

[Juanma Barranquero]

> Someone please change the CVS version to say 21.4.50, now that Emacs
> 21.3 has been released.

What about the talk for a new versioning scheme discussed nine months
ago?

http://mail.gnu.org/archive/html/emacs-devel/2002-07/msg00011.html


                                                                Juanma

Re: cvs head crash in GC

[Andreas Schwab]

"Eli Zaretskii" <eliz@elta.co.il> writes:

|> > From: Sam Steingold <sds@gnu.org>
|> > Date: 31 Mar 2003 19:24:56 -0500
|> > 
|> > GNU Emacs 21.3.50.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
|> >  of 2003-03-31 on loiso.podval.org
|> 
|> Someone please change the CVS version to say 21.4.50, now that Emacs
|> 21.3 has been released.

The next version is supposed to be 21.4 from mainline, isn't it?  So
21.3.50 is still correct.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: cvs head crash in GC

[Juanma Barranquero]

> |> Someone please change the CVS version to say 21.4.50, now that Emacs
> |> 21.3 has been released.
> 
> The next version is supposed to be 21.4 from mainline, isn't it?  So
> 21.3.50 is still correct.

The fact that not even us know for sure how to interpret the numbers
should be taken as a hint that the current scheme is not quite right...
:)


                                                                Juanma

Re: cvs head crash in GC

[Andreas Schwab]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

|> > |> Someone please change the CVS version to say 21.4.50, now that Emacs
|> > |> 21.3 has been released.
|> > 
|> > The next version is supposed to be 21.4 from mainline, isn't it?  So
|> > 21.3.50 is still correct.
|> 
|> The fact that not even us know for sure how to interpret the numbers
|> should be taken as a hint that the current scheme is not quite right...
|> :)

Every one will agree that 21.4.50 > 21.4.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: cvs head crash in GC

[Juanma Barranquero]

On Tue, 01 Apr 2003 15:33:12 +0200
Andreas Schwab <schwab@suse.de> wrote:

> Every one will agree that 21.4.50 > 21.4.

Yeah, sure.

But not everyone will agree on what that means *with respect to* Emacs
releases... ;)


                                                                Juanma

Re: cvs head crash in GC

[Eli Zaretskii]

> Date: Tue,  1 Apr 2003 08:33:23 +0000
> From: jasonr@f2s.com
> 
> > Someone please change the CVS version to say 21.4.50, now that Emacs
> > 21.3 has been released.
> 
> Does that mean we are releasing 21.4 from the RC branch, or skipping it?

Sorry, I forgot that 21.3.x is consistent with 21.4 being the next
release from HEAD.

Re: cvs head crash in GC

[Richard Stallman]

    Program received signal SIGSEGV, Segmentation fault.
    0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
    (gdb) where
    #0  0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
    #1  0x0804feee in safe_bcopy (from=0x99390cc "\2649o\b", 
	to=0x99b4458 "\324y\316\bnnimap+mail.podval.org:.imap/lisp/misc", 
	size=504716) at dispnew.c:484
    #2  0x0811c7e1 in compact_small_strings () at alloc.c:1641

It is clear that the size argument to safe_bcopy is nonsense.
A string 504716 bytes long would not be stored in "small string"
fashion.

The next step is to figure out the chain of events that occurred
in compact_small_strings.  The value that you got for FROM seems
impossible--it does not match the FROM arg in safe_bcopy.
I think that the variable FROM is not live at that point,
and its register is in use for something else or was not saved.
You can assume FROM was actually 0x99390cc.  It would be interesting
to cross-check that  against the value of FROM_END.

Please look at FROM->string; that is the Lisp_String structure.
What is in that?