core dump while in gnus

core dump while in gnus

[Ralf Fassel]

In GNU Emacs 21.2.1 (mips-sgi-irix6.5, X toolkit)
 of 2002-04-05 on merkur
configured using `configure  --prefix=/software/emacs/21.2 -exec-prefix=/software/emacs/21.2/IRIX-6 --with-pop --with-x-toolkit=athena'
Important settings:
  value of $LC_ALL: C
  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: nil

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

while running Gnus, emacs dumps core quite often.  GDB stack trace:

#0  0x101a3128 in mmap_realloc (var=0x10765808, nbytes=2125) at buffer.c:4516
#1  0x101a3750 in enlarge_buffer_text (b=0x10765800, delta=2104)
    at buffer.c:4667
#2  0x101a8c10 in make_gap (nbytes_added=2104) at insdel.c:545
#3  0x101aa0e0 in insert_from_string_1 (string=815766308, pos=0, pos_byte=0, 
    nchars=124, nbytes=124, inherit=0, before_markers=1) at insdel.c:1050
#4  0x101a9ebc in insert_from_string_before_markers (string=815766308, pos=0, 
    pos_byte=0, length=124, length_byte=124, inherit=0) at insdel.c:1012
#5  0x10299180 in read_process_output (proc=1085325184, channel=4)
    at process.c:3161
#6  0x10298208 in wait_reading_process_input (time_limit=-1, microsecs=0, 
    read_kbd=0, do_display=0) at process.c:2774
#7  0x102972fc in Faccept_process_output (process=1085325184, timeout=1, 
    timeout_msecs=273280004) at process.c:2301
#8  0x10230548 in Ffuncall (nargs=3, args=0x7fff18f0) at eval.c:2666
#9  0x1028e31c in Fbyte_code (bytestr=814417700, vector=1082850560, maxdepth=5)
    at bytecode.c:716
#10 0x10231228 in funcall_lambda (fun=1078574976, nargs=1, 
    arg_vector=0x7fff1ae4) at eval.c:2851
#11 0x10230730 in Ffuncall (nargs=2, args=0x7fff1ae0) at eval.c:2707
#12 0x1028e31c in Fbyte_code (bytestr=814417044, vector=1082857472, maxdepth=8)
    at bytecode.c:716
#13 0x10231228 in funcall_lambda (fun=1082823552, nargs=1, 
    arg_vector=0x7fff1cd4) at eval.c:2851
#14 0x10230730 in Ffuncall (nargs=2, args=0x7fff1cd0) at eval.c:2707
#15 0x1028e31c in Fbyte_code (bytestr=814408324, vector=1082851200, maxdepth=5)
    at bytecode.c:716
#16 0x10231228 in funcall_lambda (fun=1082825056, nargs=2, 
    arg_vector=0x7fff1ec4) at eval.c:2851
#17 0x10230730 in Ffuncall (nargs=3, args=0x7fff1ec0) at eval.c:2707
#18 0x1028e31c in Fbyte_code (bytestr=814181380, vector=1081054208, maxdepth=4)
    at bytecode.c:716
#19 0x10231228 in funcall_lambda (fun=1082366880, nargs=1, 
    arg_vector=0x7fff20a4) at eval.c:2851
#20 0x10230730 in Ffuncall (nargs=2, args=0x7fff20a0) at eval.c:2707
#21 0x1028e31c in Fbyte_code (bytestr=814174276, vector=1082505216, maxdepth=9)
    at bytecode.c:716
#22 0x10231228 in funcall_lambda (fun=1082367264, nargs=1, 
    arg_vector=0x7fff22a4) at eval.c:2851
#23 0x10230730 in Ffuncall (nargs=2, args=0x7fff22a0) at eval.c:2707
#24 0x1028e31c in Fbyte_code (bytestr=814268516, vector=1082686848, maxdepth=3)
    at bytecode.c:716
#25 0x10231228 in funcall_lambda (fun=1082683072, nargs=3, 
    arg_vector=0x7fff2484) at eval.c:2851
#26 0x10230730 in Ffuncall (nargs=4, args=0x7fff2480) at eval.c:2707
#27 0x1028e31c in Fbyte_code (bytestr=813374004, vector=1082130112, maxdepth=4)
    at bytecode.c:716
#28 0x10231228 in funcall_lambda (fun=1082129760, nargs=1, 
    arg_vector=0x7fff2694) at eval.c:2851
#29 0x10230730 in Ffuncall (nargs=2, args=0x7fff2690) at eval.c:2707
#30 0x102288e8 in Fcall_interactively (function=273481356, 
    record_flag=273280004, keys=1078665216) at callint.c:797
#31 0x1017e628 in Fcommand_execute (cmd=273481356, record_flag=273280004, 
    keys=273280004, special=273280004) at keyboard.c:9221
#32 0x1016964c in command_loop_1 () at keyboard.c:1644
#33 0x1022c258 in internal_condition_case (bfun=0x10167b48 <command_loop_1>, 
    handlers=273402052, hfun=0x10167250 <cmd_error>) at eval.c:1267
#34 0x101677e8 in command_loop_2 () at keyboard.c:1245
#35 0x1022ba50 in internal_catch (tag=273354404, 
    func=0x101677a8 <command_loop_2>, arg=273280004) at eval.c:1030
#36 0x10167750 in command_loop () at keyboard.c:1224
#37 0x10166c9c in recursive_edit_1 () at keyboard.c:950
#38 0x10166f2c in Frecursive_edit () at keyboard.c:1006
#39 0x1016472c in main (argc=7, argv=0x7fff2e54, envp=0x7fff2e74)
    at emacs.c:1547

(gdb) l
4511          result = mmap_alloc (var, nbytes);
4512        }
4513      else
4514        {
4515          struct mmap_region *r = MMAP_REGION (*var);
4516          size_t room = r->nbytes_mapped - MMAP_REGION_STRUCT_SIZE;
4517          
4518          if (room < nbytes)
4519            {
4520              /* Must enlarge.  */

(gdb) where 1
#0  0x101a3128 in mmap_realloc (var=0x10765808, nbytes=2125) at buffer.c:4516
(gdb) p r
$1 = (struct mmap_region *) 0x4060000
(gdb) p *r
Cannot access memory at address 0x4060000

(gdb) up
#1  0x101a3750 in enlarge_buffer_text (b=0x10765800, delta=2104)
    at buffer.c:4667
4667      p = mmap_realloc ((POINTER_TYPE **) &b->text->beg, nbytes);
(gdb) p nbytes
$2 = 2125
(gdb) p b
$3 = (struct buffer *) 0x10765800
(gdb) p b->text
$4 = (struct buffer_text *) 0x10765808
(gdb) p b->text->beg
$5 = (unsigned char *) 0x4060018 <Address 0x4060018 out of bounds>

(gdb) up
#2  0x101a8c10 in make_gap (nbytes_added=2104) at insdel.c:545
545       enlarge_buffer_text (current_buffer, nbytes_added);
(gdb) p current_buffer
$6 = (struct buffer *) 0x10765800
(gdb) p *current_buffer
$7 = {
  size = 537002092, 
  next = 0x10765200, 
  own_text = {
    beg = 0x4060018 <Address 0x4060018 out of bounds>,
    ...

The buffer in question seems to always be the NNTP process buffer
" *server news.cis.dfn.de nntp  *nntpd**"

where the process might have been disconnected due to a server
timeout. gdb is still running. so if anybody has some ideas...

R'

Re: core dump while in gnus

[Richard Stallman]

    (gdb) p *current_buffer
    $7 = {
      size = 537002092, 
      next = 0x10765200, 
      own_text = {
	beg = 0x4060018 <Address 0x4060018 out of bounds>,

If this is what happens, I suggest you add code at the places
that set the beg field which will check whether the new
value is invalid.  That way, when it happens again, you will
catch it earlier and you might be able to learn more.

Re: core dump while in gnus

[Eli Zaretskii]

On Mon, 15 Apr 2002, Richard Stallman wrote:

>     (gdb) p *current_buffer
>     $7 = {
>       size = 537002092, 
>       next = 0x10765200, 
>       own_text = {
> 	beg = 0x4060018 <Address 0x4060018 out of bounds>,
> 
> If this is what happens, I suggest you add code at the places
> that set the beg field which will check whether the new
> value is invalid.

The `size' member looks very suspicious as well, no?

Re: core dump while in gnus

[Ralf Fassel]

* Eli Zaretskii
| >     (gdb) p *current_buffer
| >     $7 = {
| >       size = 537002092, 
| >       next = 0x10765200, 
| >       own_text = {
| > 	beg = 0x4060018 <Address 0x4060018 out of bounds>,
| > 
| > If this is what happens, I suggest you add code at the places
| > that set the beg field which will check whether the new
| > value is invalid.

The problem is of course that this is the `current buffer', which is
changed quite often, and I cannot reliably reproduce this bug.
However, it should be possible to locate the last few changes when it
crashes.  I will have a check.

| The `size' member looks very suspicious as well, no?

No.  Remember, this is an EMACS_INT:

    (gdb) p 537002092
    $1 = 537002092
    (gdb) xint
    $2 = 131180

131kB is not unusual for a NNTP process buffer while reading news.

R'

Re: core dump while in gnus

[Richard Stallman]

    No.  Remember, this is an EMACS_INT:

	(gdb) p 537002092
	$1 = 537002092
	(gdb) xint
	$2 = 131180

That size field is the pseudovector object's size field.
Its value has nothing to do with the size of the text.
It is correct for a buffer.