From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: transpose-regions Date: Fri, 23 Mar 2007 10:09:48 -0400 Message-ID: <87ircst5jn.fsf@stupidchicken.com> References: <46026277.7060305@gmx.at> <87zm64kau0.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174659041 23693 80.91.229.12 (23 Mar 2007 14:10:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2007 14:10:41 +0000 (UTC) Cc: Andreas Schwab , emacs-devel , martin rudalics To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 15:10:24 2007 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 1HUkTD-0004kt-HV for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 15:10:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUkV7-00081G-FX for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 09:12:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUkV1-0007xT-5G for emacs-devel@gnu.org; Fri, 23 Mar 2007 10:12:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUkV0-0007vt-7F for emacs-devel@gnu.org; Fri, 23 Mar 2007 09:12:10 -0500 Original-Received: from south-station-annex.mit.edu ([18.72.1.2]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HUkT4-0005OZ-Uu for emacs-devel@gnu.org; Fri, 23 Mar 2007 10:10:11 -0400 Original-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l2NEA68q028726; Fri, 23 Mar 2007 09:10:06 -0500 (EST) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id l2NE9r7Q021207; Fri, 23 Mar 2007 10:09:54 -0400 (EDT) Original-Received: from localhost ([18.19.7.211]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id l2NE9mjw019853; Fri, 23 Mar 2007 10:09:49 -0400 (EDT) Original-Received: from cyd by localhost with local (Exim 3.36 #1 (Debian)) id 1HUkSi-0002RW-00; Fri, 23 Mar 2007 10:09:48 -0400 In-Reply-To: (Kim F. Storm's message of "Fri\, 23 Mar 2007 12\:50\:27 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: -2.599 X-detected-kernel: Solaris 9.1 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:68395 Archived-At: storm@cua.dk (Kim F. Storm) writes: >>> The problem seems to be that a cons cell that has already been >>> garbage-collected is being passed to Fcopy_sequence during >>> copy_properties(), in intervals.c:106. Where did this cons cell come >>> from? >>> >>> target->plist = Fcopy_sequence (source->plist); >>> >>> Is the garbage collector somehow failing to account for cons cells >>> assigned to interval plists? >> >> Unlikely, what would be a too obvious bug to remain unnoticed until now >> (and mark_interval indeed does mark the plist). More likely that the >> whole interval is not being marked in the first place. The function uses >> the local variables tmp_interval[12] that are copies of the buffer >> intervals, perhaps they need to be protected from GC? > > There's only a need to GC around a called function if that > function can actually do GC, i.e. if calling the function may > eventually call Feval or run byte code. Where is that possible? > > Besided, a native windows build uses conservative stack marking, > so it is not necessary to explicitly protect from GC (on that > platform). ut was this a native or a cygwin build? > > Perhaps the conservative stack marking does not work properly on > WindowsME (does anything work properly on ME?) I'm running on GNU/Linux with the latest CVS.