From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: segfault crash when loading certain rmail files Date: Fri, 21 Jun 2002 20:11:33 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200206211111.UAA01840@etlken.m17n.org> References: <200206170613.PAA26074@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1024657949 26853 127.0.0.1 (21 Jun 2002 11:12:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 21 Jun 2002 11:12:29 +0000 (UTC) Cc: rehmann@mathematik.uni-bielefeld.de, rms@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17LML7-0006z0-00 for ; Fri, 21 Jun 2002 13:12:29 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17LMnF-0002HR-00 for ; Fri, 21 Jun 2002 13:41:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17LMKv-0006kj-00; Fri, 21 Jun 2002 07:12:17 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17LMKG-0006iA-00; Fri, 21 Jun 2002 07:11:37 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g5LBBYl21690; Fri, 21 Jun 2002 20:11:34 +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.3/3.7W-20010823150639) with ESMTP id g5LBBY900045; Fri, 21 Jun 2002 20:11:34 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA01840; Fri, 21 Jun 2002 20:11:33 +0900 (JST) Original-To: emacs-devel@gnu.org In-Reply-To: <200206170613.PAA26074@etlken.m17n.org> (message from Kenichi Handa on Mon, 17 Jun 2002 15:13:10 +0900 (JST)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5043 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5043 I finally got a permission to contribute code again for Emacs 21! So, I can work on the following matter by myself. If any of you have already started to work on it, please let me know. --- Ken'ichi HANDA handa@etl.go.jp Kenichi Handa writes: > Ulf Rehmann writes: >> I turned out that the crash can be triggered, for emacs 21.2, by >> loading any file just containing the character (decimal) 128, if this >> file is gzipped and visited by find-file and if "automatic file >> de/compression" is toggled "on". >> No crash with emacs 20.7. > Thank you for the report. The following change will fix the > problem. > (1) Fix Fcall_process (in callproc.c). > We have this code at line 786. > repeat_decoding: > size = decoding_buffer_size (&process_coding, nread); > decoding_buf = (char *) xmalloc (size); > if (process_coding.cmp_data) process_coding.cmp_data-> char_offset = PT; > decode_coding (&process_coding, bufptr, decoding_buf, > nread, size); > Before we check process_coding.cmp_data, if process_coding > requires detection (we have the macro > CODING_REQUIRED_DETECTION for checking it), we must call > detect_coding. And, if the resulting > process_coding.composing is not COMPOSITION_DISABLED, we > must allocate a memory for handling composition data (we > have the function coding_allocate_composition_data, the > second arg must be PT). > (2) Fix detect_eol (in coding.c). > We have this code at 4316 > if (VECTORP (val) && XVECTOR (val)->size == 3) > { > int src_multibyte = coding->src_multibyte; > int dst_multibyte = coding->dst_multibyte; > setup_coding_system (XVECTOR (val)->contents[eol_type], coding); coding-> src_multibyte = src_multibyte; coding-> dst_multibyte = dst_multibyte; coding-> heading_ascii = skip; > } > The value of coding->cmp_data must be saved before calling > setup_coding_system and restored after the call. > And, we potentially have the same kind of problem in the > following places (where, decode_coding is called directly). > w16select.c:663: decode_coding (&coding, htext, buf, truelen, bufsize); > w32fns.c:6688: decode_coding (&coding, lplogfont->lfFaceName, fontname, > w32select.c:335: decode_coding (&coding, src, buf, nbytes, bufsize); > xselect.c:1651: decode_coding (&coding, data, buf, size, bufsize); > xterm.c:10688: decode_coding (&coding, copy_bufptr, p, > Fortunetly, for all those case, we can simply diable > composition handling by setting the member `composing' of > `struct coding_system' to COMPOSITION_DIABLED. For example, > in the case of xselect.c, before calling decode_coding at > the line 335, what we need is to set coding.composing to > COMPOSITION_DIABLED. > Could someone please install a fix? I'll verify the result. > --- > Ken'ichi HANDA > handa@etl.go.jp > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel