[Top][All Lists]
[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.
- SIGSEGV,
Alex Schroeder <=
- SIGSEGV, Alex Schroeder, 2002/12/28