From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs 22.2.90 pretest Date: Thu, 21 Aug 2008 09:51:33 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <87y72ymcig.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1219279915 19834 80.91.229.12 (21 Aug 2008 00:51:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2008 00:51:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 21 02:52:47 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KVyPu-0007lf-5N for ged-emacs-devel@m.gmane.org; Thu, 21 Aug 2008 02:52:47 +0200 Original-Received: from localhost ([127.0.0.1]:35422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVyOu-0001NO-VA for ged-emacs-devel@m.gmane.org; Wed, 20 Aug 2008 20:51:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVyOr-0001NJ-Sz for emacs-devel@gnu.org; Wed, 20 Aug 2008 20:51:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVyOp-0001N7-Bi for emacs-devel@gnu.org; Wed, 20 Aug 2008 20:51:40 -0400 Original-Received: from [199.232.76.173] (port=39309 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVyOp-0001N4-7V for emacs-devel@gnu.org; Wed, 20 Aug 2008 20:51:39 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:49694) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVyOk-0003KV-Ul; Wed, 20 Aug 2008 20:51:35 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 4C2512C40; Thu, 21 Aug 2008 09:51:33 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.2.90 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102745 Archived-At: >>>>> On Wed, 20 Aug 2008 19:07:02 +0300, Eli Zaretskii said: >> 2008-08-02 Eli Zaretskii >> >> * fileio.c (Fexpand_file_name): Convert the value of $HOME to a >> multibyte string. >> >> The above change contains the same problem I pointed out in >> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00026.html. >> I.e., DECODE_FILE may GC, and pointers to Lisp String contents are >> not valid after that because of relocations by compaction. > Please suggest which variables to GCPRO. GCPRO doesn't help here. It just protects Lisp Objects from being collected, but not for Lisp String contents from being relocated. Anyway GCPRO is nowadays NOOP on most platforms because of conservative GC. > The code is convoluted, but I did try to walk through it and see if > any variables need to be protected from GC. Most of the code that > uses nm[] (the only variable you mentioned back in March) is on > DOS_NT, where the original string is copied to a stack-allocated > buffer right at the beginning, and manipulated there; the original > pointer to a Lisp_Object is forgotten, so GC cannot possibly cause > harm on those platforms. Yes, `nm' is not corrupted if DOS_NT because of copying. But otherwise, it may be corrupted by GC and it is actually used afterwards. 1455 if (1 1456 #ifndef DOS_NT 1457 /* /... alone is not absolute on DOS and Windows. */ 1458 && !IS_DIRECTORY_SEP (nm[0]) 1459 #endif > Perhaps I missed something, but in that case please make specific > suggestions which variables to protect and why, because the general > principle that GC can move strings is obviously not news to me. You can find some follow-up changes by others in the trunk to address this issue, but with some `FIXME' comment. I'm not sure if it is good to apply such changes to the EMACS_22_BASE branch as that comment may imply they are somewhat experimental. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp