SEGFAULT on increment_row_positions

SEGFAULT on increment_row_positions

[JD Smith]

My programming mode IDLWAVE tends to trigger many more SEGFAULTS in
Emacs 21 than any other use of Emacs I make, but only when the IDL
shell is running as a subprocess under Comint.  In particular, when
the IDL sub-process gets quite large (IDL is a data processing
language), the SEGFAULTS seem more common, which may indicate a
garbage collection or other memory related bug (just guessing here).
I have managed today to achieve a SEGFAULT after every 10-30min of
heavy use, and found this trace:

Program received signal SIGSEGV, Segmentation fault.
0x0804fdf8 in increment_row_positions (row=0x86905a4, delta=-17, delta_bytes=4)
    at dispnew.c:1188
1188          if (BUFFERP (row->glyphs[area][i].object)
(gdb) xbacktrace
(gdb) bt
#0  0x0804fdf8 in increment_row_positions (row=0x86905a4, delta=-17,
    delta_bytes=4) at dispnew.c:1188
#1  0x0804fe7b in increment_matrix_positions (matrix=0x8a771b0, start=56,
    end=86, delta=-17, delta_bytes=-17) at dispnew.c:927
#2  0x0806b0dc in try_window_id (w=0x84b3a90) at xdisp.c:11883
#3  0x0806fe14 in redisplay_window (window=1212889744, just_this_one_p=1)
    at xdisp.c:10260
#4  0x08072334 in redisplay_internal (preserve_echo_area=4) at xdisp.c:8910
#5  0x0805710d in sit_for (sec=0, usec=100000, reading=0, display=1,
    initial_display=1) at dispnew.c:6230
#6  0x080e8f0b in command_loop_1 () at keyboard.c:1687
#7  0x0813704d in internal_condition_case (bfun=0x80e891d <command_loop_1>,
    handlers=405408900, hfun=0x80e1ca8 <cmd_error>) at eval.c:1267
#8  0x080dd899 in command_loop_2 () at keyboard.c:1245
#9  0x08136f6c in internal_catch (tag=4, func=0x80dd876 <command_loop_2>,
    arg=405312556) at eval.c:1030
#10 0x080dd6a5 in command_loop () at keyboard.c:1224
#11 0x080dd742 in recursive_edit_1 () at keyboard.c:950
#12 0x080dd85f in Frecursive_edit () at keyboard.c:1006
#13 0x080dcb44 in main (argc=3, argv=0xbffff494, envp=0xbffff4a4)
    at emacs.c:1547 #14 0x40309e23 in __libc_start_main () from
/lib/tls/libc.so.6 #15 0x0804f451 in ?? ()

This is GNU Emacs 21.3.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d
scroll bars) of 2005-02-04 on bugs.build.redhat.com running under FC3.

Any hints on pursuing this further?

These variable printouts may be of use:

(gdb) p i
$1 = 1
(gdb) p area
$2 = 1
(gdb) p row->glyphs[area][i]
$3 = {
  charpos = 3899,
  object = 1213660376,
  pixel_width = 10,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 10,
  u = {
    ch = 32,
    cmp_id = 32,
    img_id = 32,
    stretch = {
      height = 32,
      ascent = 0
    },
    val = 32
  }
}

I'll keep trying, to see where the SEGFAULT is typically occurring.

Thanks,

JD

Re: SEGFAULT on increment_row_positions

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0804fdf8 in increment_row_positions (row=0x86905a4, delta=-17, delta_bytes=4)
>     at dispnew.c:1188

I recall fixing a problem like that in CVS emacs (22.0) some time ago.


> This is GNU Emacs 21.3.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d
> scroll bars) of 2005-02-04 on bugs.build.redhat.com running under FC3.

Can you test your code with CVS emacs, to see if it fails there too?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: SEGFAULT on increment_row_positions

[David Kastrup]

JD Smith <jdsmith@as.arizona.edu> writes:

> My programming mode IDLWAVE tends to trigger many more SEGFAULTS in
> Emacs 21 than any other use of Emacs I make, but only when the IDL
> shell is running as a subprocess under Comint.  In particular, when
> the IDL sub-process gets quite large (IDL is a data processing
> language), the SEGFAULTS seem more common, which may indicate a
> garbage collection or other memory related bug (just guessing here).
> I have managed today to achieve a SEGFAULT after every 10-30min of
> heavy use, and found this trace:

This is not much help with this particular bug, but if you are
suspecting a garbage collection related problem, setting
gc-cons-threshold to a small value like 1000 should cause the problem
to occur much more often than every 10-30min, perhaps making diagnosis
and debugging easier.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: SEGFAULT on increment_row_positions

[JD Smith]

On Sat, 04 Jun 2005 01:57:49 +0200, Kim F. Storm wrote:

> JD Smith <jdsmith@as.arizona.edu> writes:
> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0804fdf8 in increment_row_positions (row=0x86905a4, delta=-17, delta_bytes=4)
>>     at dispnew.c:1188
> 
> I recall fixing a problem like that in CVS emacs (22.0) some time ago.
> 
> 
>> This is GNU Emacs 21.3.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d
>> scroll bars) of 2005-02-04 on bugs.build.redhat.com running under FC3.
> 
> Can you test your code with CVS emacs, to see if it fails there too?

Thanks Kim.  I compiled a CVS version 22.0.50.1, and indeed the problem
seems to have been solved (with about 3 hours of similar testing down).

Can you think of a reason that my mode might trigger the bug more
often?  If possible, I'd love to work around it, so that Emacs 21.X
running IDLWAVE wouldn't suffer from it.  Or is it really a generic
re-display issue that cannot be easily avoided?

Thanks again,

JD

Re: SEGFAULT on increment_row_positions

[JD Smith]

On Mon, 06 Jun 2005 10:17:26 -0700, JD Smith wrote:

> On Sat, 04 Jun 2005 01:57:49 +0200, Kim F. Storm wrote:
> 
>> JD Smith <jdsmith@as.arizona.edu> writes:
>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0804fdf8 in increment_row_positions (row=0x86905a4, delta=-17, delta_bytes=4)
>>>     at dispnew.c:1188
>> 
>> I recall fixing a problem like that in CVS emacs (22.0) some time ago.
>> 
>> 
>>> This is GNU Emacs 21.3.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d
>>> scroll bars) of 2005-02-04 on bugs.build.redhat.com running under FC3.
>> 
>> Can you test your code with CVS emacs, to see if it fails there too?
> 
> Thanks Kim.  I compiled a CVS version 22.0.50.1, and indeed the problem
> seems to have been solved (with about 3 hours of similar testing down).

Well, I spoke too soon.  I got a very similar SEGFAULT under
22.0.50.1:

Program received signal SIGSEGV, Segmentation fault.
0x08050c27 in increment_row_positions (row=0x888d384, delta=-1, delta_bytes=4)
    at dispnew.c:1190
1190          if (BUFFERP (row->glyphs[area][i].object)
(gdb) bt
#0  0x08050c27 in increment_row_positions (row=0x888d384, delta=-1,
    delta_bytes=4) at dispnew.c:1190
#1  0x08050ca6 in increment_matrix_positions (matrix=0x851a2e0, start=37,
    end=64, delta=-1, delta_bytes=-1) at dispnew.c:929
#2  0x0806e09a in try_window_id (w=0x94d10b0) at xdisp.c:13977
#3  0x08073b15 in redisplay_window (window=156045492, just_this_one_p=1)
    at xdisp.c:12260
#4  0x0807593d in redisplay_window_1 (window=156045492) at xdisp.c:10975
#5  0x0813a69c in internal_condition_case_1 (
    bfun=0x8075910 <redisplay_window_1>, arg=156045492, handlers=137328837,
    hfun=0x806b168 <redisplay_window_error>) at eval.c:1430
#6  0x08076bf0 in redisplay_internal (preserve_echo_area=4) at xdisp.c:10574
#7  0x080e6049 in read_char (commandflag=1, nmaps=2, maps=0xbfffed40,
    prev_event=137302033, used_mouse_menu=0xbfffed88) at keyboard.c:2539
#8  0x080e8bf6 in read_key_sequence (keybuf=0xbfffeea0, bufsize=30,
    prompt=137302033, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8818
#9  0x080ea4fb in command_loop_1 () at keyboard.c:1527
#10 0x0813a5aa in internal_condition_case (bfun=0x80ea368 <command_loop_1>,
    handlers=137363001, hfun=0x80e4384 <cmd_error>) at eval.c:1389
#11 0x080ded52 in command_loop_2 () at keyboard.c:1318
#12 0x0813a4b9 in internal_catch (tag=4, func=0x80ded34 <command_loop_2>,
    arg=137302033) at eval.c:1148
#13 0x080deb61 in command_loop () at keyboard.c:1297
#14 0x080debfb in recursive_edit_1 () at keyboard.c:990
#15 0x080decf6 in Frecursive_edit () at keyboard.c:1051
#16 0x080de07d in main (argc=2, argv=0xbffff4a4) at emacs.c:1775

(gdb) p row->glyphs[area][i]
$2 = {
  charpos = 4980,
  object = 148914700,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 18,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
    ch = 119,
    cmp_id = 119,
    img_id = 119,
    stretch = {
      height = 119,
      ascent = 0
    },
    val = 119
  }
}

I am using glyphs in the margin to mark breakpoints, and it appears
that these glyphs must be active to trip this bug (so my several hours
of uptime I reported before didn't count).  I had used these
breakpoint glyphs for an hour before experiencing the crash, so it's
not a simple one.  Any recommendations?

JD