From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Kalman Reti" Newsgroups: gmane.emacs.devel,gmane.emacs.bugs Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight) Date: Fri, 16 Nov 2007 12:56:21 -0500 Message-ID: <16af2f430711160956w6615fdbak7cf07f6cd2789b6f@mail.gmail.com> References: <16af2f430711081955j3d5e6745gc0f7a50e02d9a892@mail.gmail.com> <16af2f430711140939x45663644je0dce25c8796b18@mail.gmail.com> <16af2f430711141700g74175advd8f234478293faa5@mail.gmail.com> <16af2f430711160405p6a734839lb24610ee65257498@mail.gmail.com> <16af2f430711160607m158b9c98xa401166709f628ff@mail.gmail.com> <473DD32F.5070501@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195235843 31392 80.91.229.12 (16 Nov 2007 17:57:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2007 17:57:23 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, kalman.reti@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: "martin rudalics" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 16 18:57:27 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 1It5RO-00013C-EK for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2007 18:57:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1It5RB-00063T-HY for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2007 12:57:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1It5QX-000578-LT for emacs-devel@gnu.org; Fri, 16 Nov 2007 12:56:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1It5QW-00054O-Dm for emacs-devel@gnu.org; Fri, 16 Nov 2007 12:56:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1It5QW-00053I-4S for emacs-devel@gnu.org; Fri, 16 Nov 2007 12:56:24 -0500 Original-Received: from nz-out-0506.google.com ([64.233.162.233]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1It5QV-0007AI-9I for emacs-devel@gnu.org; Fri, 16 Nov 2007 12:56:23 -0500 Original-Received: by nz-out-0506.google.com with SMTP id f1so898480nzc for ; Fri, 16 Nov 2007 09:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DjhYnsS5AWlVUn9QQjrcolA/YdELRUwrMhOntuDKwy0=; b=RZouSk9DT5V7Gkdh2VmT948LFIx3DpdlT+zsexsCkIzXNrcrYXltqxAuQWUiXrQniNCyWORlYtHFZSQzPbQUwvsY0EPmyTEyDJBOKDw5oLJnlajBvp0yTasRIVJBFrMG2LkY9T9ZZd5Lm2A1/T95a6kGJ2ij1FIi7xuD5ttSvt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hPUkMBzHyi10kQ7pBIhp3qaavT3ZWEBxepAWHtqjn2+fKfiDwJN4kLANS/TUZPx8osJCUG5HHufwy6iNRvhcdvVfPEv7s9VcRiMgdMtlMgSXJTuHwDtSE5J0faWUwxeMqnhUK3S2oVV/rDo4zqgqKmKsNjh8P8Io7y1xPqd7cUU= Original-Received: by 10.142.231.7 with SMTP id d7mr712513wfh.1195235781926; Fri, 16 Nov 2007 09:56:21 -0800 (PST) Original-Received: by 10.143.167.19 with HTTP; Fri, 16 Nov 2007 09:56:21 -0800 (PST) In-Reply-To: <473DD32F.5070501@gmx.at> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:83359 gmane.emacs.bugs:16992 Archived-At: On Nov 16, 2007 12:28 PM, martin rudalics wrote: > Do you mean in code wrapped in `save-match-data' you delete some region > of text containing a marker of the saved match-data. It isn't in my code, it is in the shell-command function in simple.el, but essentially this is correct. Most of the guts of calling the subprocess to generate the output is inside save-match-data; I don't know exactly what path results in the markers' getting on the undo list, but if I create a new macro save-match-data-noevaporate that is identical to the original minus the 'evaporate argument to set-match-data and use that inside of shell-command instead of the original, my crash goes away. > Thus > record_marker_adjustment puts an entry on `buffer-undo-list' referencing > that marker. The unwindforms of `save-match-data' call `set-match-data' > with evaporate/reseat non-nil, which calls free_marker and subsequently > free_misc. mark_object - operating from `buffer-undo-list' - detects > that the object is already free and aborts. There is something which causes this not to happen all the time which I have not yet found. If you are lucky and this "something" happens before the next GC, all is well. I'd been doing exactly the same sorts of shell operations in elisp functions for years before encountering one big enough to have a 100% chance of being unlucky. It does many hundreds of shell operations (perhaps even thousands, I haven't counted them) taking many minutes. > > If I understand correctly, this means that either markers used for > saving match-data should not go to `buffer-undo-list' or the "evaporate" > option set by `save-match-data' is inherently broken. > My suspicion is that the save-match-data was intended to be wrapped around very short local uses of markers, not the collection of arbitrary amounts of shell stdout output...