From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Kalman Reti" Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight) Date: Fri, 16 Nov 2007 07:05:29 -0500 Message-ID: <16af2f430711160405p6a734839lb24610ee65257498@mail.gmail.com> References: <16af2f430711081955j3d5e6745gc0f7a50e02d9a892@mail.gmail.com> <16af2f430711090332x39c8c768gb01d1dc6a0e4f427@mail.gmail.com> <16af2f430711120340q27926877tf976ef397d12df16@mail.gmail.com> <16af2f430711140939x45663644je0dce25c8796b18@mail.gmail.com> <16af2f430711141700g74175advd8f234478293faa5@mail.gmail.com> 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 1195214749 19755 80.91.229.12 (16 Nov 2007 12:05:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2007 12:05:49 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, kalman.reti@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 16 13:05:54 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IszxI-0007Ve-DI for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2007 13:05:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iszx5-0001jZ-Cc for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2007 07:05:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iszwz-0001j0-6J for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2007 07:05:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iszwy-0001io-FD for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2007 07:05:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iszwy-0001if-8l for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2007 07:05:32 -0500 Original-Received: from nz-out-0506.google.com ([64.233.162.232]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iszwx-0002IB-Jo for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2007 07:05:31 -0500 Original-Received: by nz-out-0506.google.com with SMTP id f1so810002nzc for ; Fri, 16 Nov 2007 04:05:30 -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=yP9e94sZn0tTpD11Ga+2Y9bnYIDOlgFUoI0f8dPlSW4=; b=hRcuTdY4USWUBztvusj+oEanA5jQtvBwmzzyersGm9sHRlnCDPHo+qdgClpnUiv44PeNJMhJQrcmtd9v3S0LnJk0ucMvTXtJM6gqAAoDMJj07xJ865kEC5M/cvK1PE6rHIDK8JfsnON51PiVeCBVnFbS65OFaInpLY37FXxFAh0= 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=GQeZjMfjpZVEuWQblpCaXUDdsXQTg7orKQf4+bkrRUtm+Rsb6/u+bjan/PY9Yi8FopJmjpU2uR87wc3XxcWdQmVZ0KMC2Mu9lQp9c8fvvSmva5885kFb20ofnUS8te4MyEftQ215W3T8iXGOXCEXmxhXGBI/EVAljtJb6/askWQ= Original-Received: by 10.142.221.19 with SMTP id t19mr548295wfg.1195214729652; Fri, 16 Nov 2007 04:05:29 -0800 (PST) Original-Received: by 10.143.167.19 with HTTP; Fri, 16 Nov 2007 04:05:29 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16990 gmane.emacs.devel:83336 Archived-At: On Nov 15, 2007 12:09 PM, Richard Stallman wrote: > I've done some more experiments; it occurred to me that if the marker in the > undo list was gc-marked already when we got to the special processing, then > it would be skipped. > > I looked to see what you mean, and I see that some elements do get > removed from the undo list. I hadn't remembered that -- sorry. > > Is this the special processing you mean? > > /* If a buffer's undo list is Qt, that means that undo is > turned off in that buffer. Calling truncate_undo_list on > Qt tends to return NULL, which effectively turns undo back on. > So don't call truncate_undo_list if undo_list is Qt. */ > if (! EQ (nextb->undo_list, Qt)) > { > ... > Yes. > If so, it is supposed to delete elements for markers > that weren't already marked by GC. And then it marks the undo > list in the normal way. I believe it works to do this if you move the undo_list before name. Otherwise, everything on the list is already marked by the normal "start at the name offset and mark until you've reached the buffer struct size" mechanism. > > Does it look like that code failed to remove an element > which was supposed to update a marker? No, it looks like a marker in the list is already marked; this marker gets turned into the Lisp_Misc_Free cell. > > Was the marker already corrupted (replaced with Lisp_Misc_Free) > before the start of the loop? I believe so. I think the culprit is the free_marker call in Fset_match_data. I think this because I added a checking routine which, given a marker, looped over all the cells in all the undo lists of all the buffers to see if that marker was in the caar of one of them, calling a dummy routine (krabort, on which I could set a breakpoint) if so. I added a call to this checking routine in free_misc, fired up my test case and almost immediately got a hit. (The backtrace below can't be the whole story, since this happens much earlier than the crash. A gdb session which is automatically capturing a backtrace at this point and continuing, so I can show you the latest stack trace before the crash, has run overnight now without reaching the crash. Presumably there is some mechanism which removes the Lisp_Misc_Free cell created here before the GC trips over it and that something else [much] later on is causing that mechanism to fail to work in the runnup to the crash.) The early stack trace is at the end of this message. One thing that isn't clear to me is exactly who is calling set-match-data with the reseat argument set to evaporate inside of the shell-command function. This is happening somewhere inside of the shell-command function which my code calls. (gdb) where #0 krabort () at alloc.c:3364 #1 0x08129319 in check_for_problem (marker=147919074) at alloc.c:3380 #2 0x0812934c in free_misc (misc=147919074) at alloc.c:3394 #3 0x0811c354 in Fset_match_data (list=146951973, reseat=137508953) at search.c:3057 #4 0x0813e252 in Ffuncall (nargs=3, args=0xbffea3f0) at eval.c:3027 #5 0x08161c84 in Fbyte_code (bytestr=136239067, vector=136239092, maxdepth=24) at bytecode.c:679 #6 0x0813d87e in Feval (form=136239053) at eval.c:2361 #7 0x0813b22f in Fprogn (args=136239045) at eval.c:450 #8 0x0813eb33 in unbind_to (count=25, value=137414769) at eval.c:3378 #9 0x08162361 in Fbyte_code (bytestr=136238739, vector=136238756, maxdepth=64) at bytecode.c:890 #10 0x0813e73a in funcall_lambda (fun=136238676, nargs=1, arg_vector=0xbffea6e4) at eval.c:3211 #11 0x0813e359 in Ffuncall (nargs=2, args=0xbffea6e0) at eval.c:3081 #12 0x08161c84 in Fbyte_code (bytestr=144608715, vector=144609972, maxdepth=64) at bytecode.c:679 #13 0x0813e73a in funcall_lambda (fun=144610268, nargs=5, arg_vector=0xbffea804) at eval.c:3211 #14 0x0813e359 in Ffuncall (nargs=6, args=0xbffea800) at eval.c:3081 #15 0x08161c84 in Fbyte_code (bytestr=144597347, vector=144598732, maxdepth=48) at bytecode.c:679 #16 0x0813e73a in funcall_lambda (fun=144598884, nargs=3, arg_vector=0xbffea924) at eval.c:3211 #17 0x0813e359 in Ffuncall (nargs=4, args=0xbffea920) at eval.c:3081 #18 0x08161c84 in Fbyte_code (bytestr=144645315, vector=144646532, maxdepth=56) at bytecode.c:679 #19 0x0813e73a in funcall_lambda (fun=144646748, nargs=3, arg_vector=0xbffea9e0) at eval.c:3211 #20 0x0813e486 in apply_lambda (fun=144646748, args=146894853, eval_flag=1) at eval.c:3135 #21 0x0813d9d3 in Feval (form=146896869) at eval.c:2415 #22 0x0813b359 in Fsetq (args=146896861) at eval.c:552 #23 0x0813d70a in Feval (form=146896853) at eval.c:2302 #24 0x0813d7dd in Feval (form=146896845) at eval.c:2340 #25 0x0813e23f in Ffuncall (nargs=2, args=0xbffead34) at eval.c:3024 #26 0x08161c84 in Fbyte_code (bytestr=136525275, vector=136525292, maxdepth=24) at bytecode.c:679 #27 0x0813e73a in funcall_lambda (fun=136525236, nargs=1, arg_vector=0xbffeae44) at eval.c:3211 #28 0x0813e359 in Ffuncall (nargs=2, args=0xbffeae40) at eval.c:3081 #29 0x08161c84 in Fbyte_code (bytestr=136525523, vector=136525540, maxdepth=24) at bytecode.c:679 #30 0x0813e73a in funcall_lambda (fun=136525484, nargs=1, arg_vector=0xbffeaf54) at eval.c:3211 #31 0x0813e359 in Ffuncall (nargs=2, args=0xbffeaf50) at eval.c:3081 #32 0x08161c84 in Fbyte_code (bytestr=136523723, vector=136523740, maxdepth=16) at bytecode.c:679 #33 0x0813e73a in funcall_lambda (fun=136523692, nargs=0, arg_vector=0xbffeb084) at eval.c:3211 #34 0x0813e359 in Ffuncall (nargs=1, args=0xbffeb080) at eval.c:3081 #35 0x0813df04 in apply1 (fn=137580545, arg=137414769) at eval.c:2765 #36 0x08139bcc in Fcall_interactively (function=137580545, record_flag=137414769, keys=137463044) at callint.c:385 #37 0x080edd6d in Fcommand_execute (cmd=137580545, record_flag=137414769, keys=137414769, special=137414769) at keyboard.c:10435 #38 0x080e3e99 in command_loop_1 () at keyboard.c:1939 #39 0x0813c6f2 in internal_condition_case (bfun=0x80e31a4 , handlers=137472161, hfun=0x80e2c70 ) at eval.c:1493 #40 0x080e2f42 in command_loop_2 () at keyboard.c:1396 #41 0x0813c263 in internal_catch (tag=137463729, func=0x80e2f24 , arg=137414769) at eval.c:1229 #42 0x080e2ed0 in command_loop () at keyboard.c:1375 #43 0x080e28f4 in recursive_edit_1 () at keyboard.c:984 #44 0x080e2a34 in Frecursive_edit () at keyboard.c:1046 #45 0x080e18c9 in main (argc=3, argv=0xbffeb834) at emacs.c:1777 Lisp Backtrace: "set-match-data" (0xbffea3f4) "byte-code" (0xbffea480) "shell-command" (0xbffea6e4) "diffs-between-depot-and-client-different-branches" (0xbffea804) "diffs-between" (0xbffea924) "changesets-between" (0xbffea9e0) "setq" (0xbffeab68) "length" (0xbffeac28) "eval" (0xbffead38) "eval-last-sexp-1" (0xbffeae44) "eval-last-sexp" (0xbffeaf54) "eval-print-last-sexp" (0xbffeb084) "call-interactively" (0xbffeb230) (gdb)