From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.mail.mew.general,gmane.emacs.devel Subject: [mew-int 01671] Re: GC crashes Date: Wed, 3 Dec 2003 08:37:08 +0900 (JST) Message-ID: <200312022337.IAA02026@etlken.m17n.org> References: <20031124.110938.193696628.wl@gnu.org> <200311260203.LAA26808@etlken.m17n.org> <20031128.103107.41640217.wl@gnu.org> <200312011240.VAA05762@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1070411522 17658 80.91.224.253 (3 Dec 2003 00:32:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2003 00:32:02 +0000 (UTC) Cc: wl@gnu.org, mew-int@mew.org, emacs-devel@gnu.org Original-X-From: mew-int-return-1671-gmmg-mew-int=m.gmane.org@mew.org Wed Dec 03 01:31:59 2003 Return-path: Original-Received: from mew2.iijlab.net ([202.232.15.102]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1ARKvu-00041k-00 for ; Wed, 03 Dec 2003 01:31:58 +0100 Original-Received: (qmail 24236 invoked by uid 7800); 3 Dec 2003 00:31:54 -0000 Mailing-List: contact mew-int-help@mew.org; run by ezmlm Precedence: bulk List-Unsubscribe: Original-Received: (qmail 23911 invoked from network); 2 Dec 2003 23:37:25 -0000 Original-Received: from unknown (HELO tsukuba.m17n.org) (192.47.44.130) by 202.232.15.102 with SMTP; 2 Dec 2003 23:37:25 -0000 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id hB2Nb9h05517; Wed, 3 Dec 2003 08:37:09 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id hB2Nb9s00739; Wed, 3 Dec 2003 08:37:09 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id IAA02026; Wed, 3 Dec 2003 08:37:08 +0900 (JST) Original-To: monnier@IRO.UMontreal.CA In-reply-to: (message from Stefan Monnier on 02 Dec 2003 11:25:16 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-ML-Name: mew-int X-Mail-Count: 01671 Xref: main.gmane.org gmane.mail.mew.general:597 gmane.emacs.devel:18298 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18298 In article , Stefan Monnier 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 , arg=675020556) at intervals.c:207 #6 0x0816a404 in traverse_intervals_noorder (tree=0x865b4fc, function=0x811dd30 , arg=675020556) at intervals.c:212 #7 0x0816a404 in traverse_intervals_noorder (tree=0x865b534, function=0x811dd30 , arg=675020556) at intervals.c:212 #8 0x0816a404 in traverse_intervals_noorder (tree=0x865b278, function=0x811dd30 , arg=675020556) at intervals.c:212 #9 0x0816a404 in traverse_intervals_noorder (tree=0x865b738, function=0x811dd30 , arg=675020556) at intervals.c:212 #10 0x0816a404 in traverse_intervals_noorder (tree=0x8925244, function=0x811dd30 , 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