Re: SIGSEGV

[Alex Schroeder]

Well, I am going to shut it down now, because I want to get some
sleep.  So here is some of the random peeking I've been doing.

(gdb) bt
#0  0x0805040d in increment_row_positions (row=0x9763950, delta=1, 
delta_bytes=1) at dispnew.c:1188
#1  0x0804fd36 in increment_matrix_positions (matrix=0x84787e0, start=50, 
end=58, delta=1, delta_bytes=1) at dispnew.c:927
#2  0x080664d0 in redisplay_internal (preserve_echo_area=0) at xdisp.c:8712
#3  0x080657e0 in redisplay () at xdisp.c:8284
#4  0x080d27b5 in read_char (commandflag=1, nmaps=2, maps=0xbffff5c4, 
prev_event=405209180, used_mouse_menu=0xbffff60c) at keyboard.c:2281
#5  0x080d9203 in read_key_sequence (keybuf=0xbffff714, bufsize=30, 
prompt=405209180, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1)
    at keyboard.c:8191
#6  0x080d1384 in command_loop_1 () at keyboard.c:1440
#7  0x08122249 in internal_condition_case (bfun=0x80d1090 <command_loop_1>, 
handlers=405305524, hfun=0x80d0cd4 <cmd_error>) at eval.c:1267
#8  0x080d0f68 in command_loop_2 () at keyboard.c:1245
#9  0x08121ddd in internal_catch (tag=405267108, func=0x80d0f44 
<command_loop_2>, arg=405209180) at eval.c:1030
#10 0x080d0f17 in command_loop () at keyboard.c:1224
#11 0x080d0a91 in recursive_edit_1 () at keyboard.c:950
#12 0x080d0bc0 in Frecursive_edit () at keyboard.c:1006
#13 0x080cfaef in main (argc=1, argv=0xbffffcd4, envp=0xbffffcdc) at 
emacs.c:1547
(gdb) up
#1  0x0804fd36 in increment_matrix_positions (matrix=0x84787e0, start=50, 
end=58, delta=1, delta_bytes=1) at dispnew.c:927
927         increment_row_positions (matrix->rows + start, delta, delta_bytes);
(gdb) p matrix
$7 = (struct glyph_matrix *) 0x84787e0
(gdb) p dump_glyph_matrix (matrix, 2)
No symbol "dump_glyph_matrix" in current context.

Guess GLYPH_DEBUG is not defined...

I dunno, I guess I should debug this some other way.  The problem is
that these crashes (if they have indeed the same source) happen very
rarely...

Alex.



Alex Schroeder <address@hidden> writes:

> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English, because the Emacs maintainers do not have
> translators to read other languages for them.
>
> Your bug report will be posted to the address@hidden mailing list.
>
> In GNU Emacs 21.2.92.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2002-11-22 on confusibombus
> Important settings:
>   value of $LC_ALL: nil
>   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: C
>   locale-coding-system: nil
>   default-enable-multibyte-characters: t
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> I was using Emacs and the Emacs IRC Client (not yet included in
> Emacs), and I was exchanging some Japanese text with other people on
> the net.  I run Emacs under GDB.  So suddenly, I cannot remember what
> I did exactly, Emacs is dead and in GDB I see this:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0805040d in increment_row_positions (row=0x9763950, delta=1, delta_bytes=1) 
> at dispnew.c:1188
> 1188          if (BUFFERP (row->glyphs[area][i].object)
> (gdb) 
>
> Unfortunately, I know nothing of the display engine...
>
> (gdb) l
> 1183      MATRIX_ROW_END_BYTEPOS (row) += delta_bytes;
> 1184
> 1185      /* Increment positions in glyphs.  */
> 1186      for (area = 0; area < LAST_AREA; ++area)
> 1187        for (i = 0; i < row->used[area]; ++i)
> 1188          if (BUFFERP (row->glyphs[area][i].object)
> 1189              && row->glyphs[area][i].charpos > 0)
> 1190            row->glyphs[area][i].charpos += delta;
>
> So I skimmed through etc/DEBUG and found this:
>
>     Note: It is not a good idea to try `pr' if you know that Emacs is
>     in deep trouble: its stack smashed (e.g., if it encountered
>     SIGSEGV due to stack overflow), or crucial data structures, such
>     as `obarray', corrupted, etc.  In such cases, the Emacs subroutine
>     called by `pr' might make more damage, like overwrite some data
>     that is important for debugging the original problem.
>
> Now, I did get a SIGSEGV, but I am not sure this means that I should
> refrain from using pr.  Am I in "deep" trouble?  :)
>
> Anyway, let me examine this loop, first.
>
> (gdb) p area
> $1 = 4159400
> (gdb) p i
> $2 = 150
>
> Ok, then I tried to find the value for LAST_AREA.  I did not find it
> with a grep through the sources, but I did not look too hard.  Then a
> silly test:
>
> (gdb) p LAST_AREA
> $3 = LAST_AREA
>
> Ok, time to check the loop boundaries:
>
> (gdb) p row->used[area]
> Cannot access memory at address 0x9f528b0
>
> Perhaps this area value is too high?
>
> The parameters:
>
> (gdb) p row
> $4 = (struct glyph_row *) 0x9763950
> (gdb) p delta
> $5 = 1
> (gdb) p delta_bytes
> $6 = 4
>
> Anyway, I do not feel like keeping this gdb + emacs running forever,
> since the computer stands in the same room where I sleep...  What can
> I do now?
>
> I am also on #emacs at irc.freenode.org as kensanata.  ;)
>
> Alex.