emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SIGSEGV


From: Alex Schroeder
Subject: SIGSEGV
Date: Sat, 28 Dec 2002 21:05:10 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.92 (i686-pc-linux-gnu)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]