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 01661] Re: GC crashes Date: Mon, 1 Dec 2003 21:40:27 +0900 (JST) Message-ID: <200312011240.VAA05762@etlken.m17n.org> References: <20031124.110938.193696628.wl@gnu.org> <200311260203.LAA26808@etlken.m17n.org> <20031128.103107.41640217.wl@gnu.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 1070291781 6940 80.91.224.253 (1 Dec 2003 15:16:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2003 15:16:21 +0000 (UTC) Cc: emacs-devel@gnu.org, mew-int@mew.org Original-X-From: mew-int-return-1661-gmmg-mew-int=m.gmane.org@mew.org Mon Dec 01 16:16:18 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 1AQpmb-0007Lp-00 for ; Mon, 01 Dec 2003 16:16:17 +0100 Original-Received: (qmail 10193 invoked by uid 7800); 1 Dec 2003 15:16:08 -0000 Mailing-List: contact mew-int-help@mew.org; run by ezmlm Precedence: bulk List-Unsubscribe: Original-Received: (qmail 9590 invoked from network); 1 Dec 2003 12:40:31 -0000 Original-Received: from unknown (HELO tsukuba.m17n.org) (192.47.44.130) by 202.232.15.102 with SMTP; 1 Dec 2003 12:40:31 -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 hB1CeSh29160; Mon, 1 Dec 2003 21:40:28 +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 hB1CeRs14824; Mon, 1 Dec 2003 21:40:27 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id VAA05762; Mon, 1 Dec 2003 21:40:27 +0900 (JST) Original-To: wl@gnu.org In-reply-to: <20031128.103107.41640217.wl@gnu.org> (message from Werner LEMBERG on Fri, 28 Nov 2003 10:31:07 +0100 (CET)) 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: 01661 Xref: main.gmane.org gmane.mail.mew.general:586 gmane.emacs.devel:18243 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18243 In article <20031128.103107.41640217.wl@gnu.org>, Werner LEMBERG writes: > [1 ] >> Please find a way to reproduce this bug by emacs started >> with -q. > I can't :-( It seems to be an interaction with running mewl (a program > from the mew package which extracts header information from emails, > sending them to the +inbox buffer) and ctext encoding. mewl runs as a > background process; I normally start reading the emails while mewl is > still running, augmenting the current buffer with header lines. So > the bug seems to be that visiting a buffer in ctext encoding which is > still augmented, and which contains many different scripts, causes a > crash. 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? The strange thing is that the change for making a composition hash table weak is done on 2003-01-10, about a year ago. I don't know why the current problem appears recently for you. --- Ken'ichi HANDA handa@m17n.org Index: composite.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/composite.c,v retrieving revision 1.29 retrieving revision 1.30 diff -u -c -r1.29 -r1.30 cvs server: conflicting specifications of output style *** composite.c 1 Sep 2003 15:45:52 -0000 1.29 --- composite.c 1 Dec 2003 12:33:13 -0000 1.30 *************** *** 843,849 **** args[0] = QCtest; args[1] = Qequal; args[2] = QCweakness; ! args[3] = Qt; args[4] = QCsize; args[5] = make_number (311); composition_hash_table = Fmake_hash_table (6, args); --- 843,851 ---- args[0] = QCtest; args[1] = Qequal; args[2] = QCweakness; ! /* Fixme: It seems that a weak hash table leads to segfault in GC, ! but I have not yet found why. -- handa@m17n.org */ ! args[3] = Qnil; args[4] = QCsize; args[5] = make_number (311); composition_hash_table = Fmake_hash_table (6, args);