From: Kenichi Handa <handa@m17n.org>
Cc: wl@gnu.org, mew-int@mew.org, emacs-devel@gnu.org
Subject: [mew-int 01671] Re: GC crashes
Date: Wed, 3 Dec 2003 08:37:08 +0900 (JST) [thread overview]
Message-ID: <200312022337.IAA02026@etlken.m17n.org> (raw)
In-Reply-To: <jwvwu9fnq88.fsf-monnier+emacs/devel@vor.iro.umontreal.ca> (message from Stefan Monnier on 02 Dec 2003 11:25:16 -0500)
In article <jwvwu9fnq88.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Thank you. It's a useful information. Now I can reproduce
>> the similar misterious segfault in GC without process nor
>> code conversion. I've just installed the attached change.
>> It seems that it fixes the problem, but I still don't
>> understand why a week hash table causes a problem. Anyway,
>> could you please try again with the latest CVS HEAD?
> Could you give us a brief description of what the table is used for,
> how it's used, how it relates to the crash, as well as a description
> of the crash (way to reproduce it, backtrace, ...) ?
We put `composition' property to text to compose characters
on displaying. The property value is a list that controls
how to compose characters.
The composition hash table is used for two purpose.
(1) It is not that fast to parse the property value and
generate a C structure (struct composition) that can be
directly used by the display routine. So, eash such C
structure is stored in an internal table (composition
table) and the hash table is used to quickly map a
property value to an index into the composition table.
(2) To reduce the number of conses, if the property value is
the same (`equal') as what stored as a key in the hash
table, replace the property value with the key.
If the composition hash table is weak, GC can remove
key-value pair from the table when a text that contains key
as `composition' property is deleted (for instance by
killing a buffer).
The crash can be preproduced by this Emacs
GNU Emacs 21.3.50.77 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
by doing this (of course by undoing my fix):
C-u C-h t thai RET
C-v (repeatedly until you reach the bottom)
C-x k RET
M-x garbage-collect RET
C-u C-h t thai RET
C-v (repeatedly)
You'll encounter segfault before you reach the bottom.
(gdb) bt
#0 0x4030f781 in kill () from /lib/libc.so.6
#1 0x080d983a in abort () at emacs.c:417
#2 0x08121055 in mark_object (arg=-67117202) at alloc.c:5046
#3 0x08120e4b in mark_object (arg=-1466419800) at alloc.c:4923
#4 0x0811dd48 in mark_interval (i=0x865b518, dummy=675020556) at alloc.c:1191
#5 0x0816a3e9 in traverse_intervals_noorder (tree=0x865b518,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:207
#6 0x0816a404 in traverse_intervals_noorder (tree=0x865b4fc,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#7 0x0816a404 in traverse_intervals_noorder (tree=0x865b534,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#8 0x0816a404 in traverse_intervals_noorder (tree=0x865b278,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#9 0x0816a404 in traverse_intervals_noorder (tree=0x865b738,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#10 0x0816a404 in traverse_intervals_noorder (tree=0x8925244,
function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#11 0x0811dd68 in mark_interval_tree (tree=0x8925244) at alloc.c:1206
#12 0x08121094 in mark_buffer (buf=-2007051104) at alloc.c:5066
[...]
This segfault always happens while marking a buffer that
contains `composition' property (in the above case, it's
TUTORIAL.th). So, I doubted the composition hash table and
made it strong, then the segfault disappeared.
---
Ken'ichi HANDA
handa@m17n.org
next prev parent reply other threads:[~2003-12-02 23:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-24 10:09 GC crashes Werner LEMBERG
2003-11-26 2:03 ` Kenichi Handa
2003-11-28 9:31 ` [mew-int 01653] " Werner LEMBERG
2003-12-01 12:40 ` [mew-int 01661] " Kenichi Handa
2003-12-02 8:31 ` [mew-int 01666] " Werner LEMBERG
2003-12-02 16:25 ` Stefan Monnier
2003-12-02 23:37 ` Kenichi Handa [this message]
2003-12-03 17:25 ` Stefan Monnier
2003-12-03 23:19 ` Kenichi Handa
2003-12-03 23:58 ` [mew-int 01678] " Stefan Monnier
2003-12-04 0:29 ` Stefan Monnier
2003-12-04 1:12 ` Kenichi Handa
2003-12-04 2:21 ` Kenichi Handa
2003-12-04 15:48 ` Stefan Monnier
2003-12-08 2:31 ` Kenichi Handa
2003-12-08 2:52 ` Stefan Monnier
2003-12-08 5:01 ` Kenichi Handa
2003-12-08 5:16 ` Stefan Monnier
2003-12-08 6:05 ` Kenichi Handa
2003-12-08 6:25 ` Stefan Monnier
2003-12-08 7:14 ` Kenichi Handa
2003-11-26 14:24 ` Stefan Monnier
2003-12-02 7:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200312022337.IAA02026@etlken.m17n.org \
--to=handa@m17n.org \
--cc=emacs-devel@gnu.org \
--cc=mew-int@mew.org \
--cc=wl@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).