From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15794: Core dump after SIGTERM during GC marking Date: Tue, 05 Nov 2013 19:16:51 +0200 Message-ID: <83y5527oqk.fsf@gnu.org> References: <87k3gq2dpr.fsf@igel.home> <83d2mh9ydm.fsf@gnu.org> <877gcp2wiz.fsf@igel.home> <83a9hl9sau.fsf@gnu.org> <8738nd2kig.fsf@igel.home> <83zjpk96qr.fsf@gnu.org> <83y554889t.fsf@gnu.org> <83bo1y976a.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1383671902 7159 80.91.229.3 (5 Nov 2013 17:18:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2013 17:18:22 +0000 (UTC) Cc: schwab@suse.de, 15794@debbugs.gnu.org To: Barry OReilly Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 05 18:18:25 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VdkGi-00021w-N1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Nov 2013 18:18:20 +0100 Original-Received: from localhost ([::1]:57623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdkGi-0004eD-9c for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Nov 2013 12:18:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdkGW-0004SO-11 for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2013 12:18:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdkGQ-0004BD-Pj for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2013 12:18:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdkGQ-0004B6-MJ for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2013 12:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VdkGQ-0006lP-BY for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2013 12:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Nov 2013 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15794 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15794-submit@debbugs.gnu.org id=B15794.138367182925942 (code B ref 15794); Tue, 05 Nov 2013 17:18:02 +0000 Original-Received: (at 15794) by debbugs.gnu.org; 5 Nov 2013 17:17:09 +0000 Original-Received: from localhost ([127.0.0.1]:36080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VdkFZ-0006kK-3k for submit@debbugs.gnu.org; Tue, 05 Nov 2013 12:17:09 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47148) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VdkFW-0006ji-Vy for 15794@debbugs.gnu.org; Tue, 05 Nov 2013 12:17:08 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MVS00C00VCEB300@a-mtaout20.012.net.il> for 15794@debbugs.gnu.org; Tue, 05 Nov 2013 19:16:57 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MVS00C7WW044S90@a-mtaout20.012.net.il>; Tue, 05 Nov 2013 19:16:53 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80035 Archived-At: > Date: Tue, 5 Nov 2013 11:52:09 -0500 > From: Barry OReilly > Cc: Andreas Schwab , 15794 <15794@debbugs.gnu.org> > > Since I can't reproduce the original crash, I am trying other means of > gathering evidence. I understand. I'm just saying that you don't necessarily see the same problem. > A SIGTERM could be handled at any time right? > Including as in this artificial reproduction. Yes, but the effect and the results could be different. > > But the Lisp backtrace doesn't tell which function of the > > kill-emacs-hook was running, > > Yes it does. The hook is ede-save-cache. It is one of the two hooks my > configuration sets up, as I indicated earlier. Maybe, but I will believe that when I see it explicitly. Backtraces from optimized builds are not to be trusted too much. > > and GC didn't really start doing its job, so it's not exactly the > > same crash. > > It is after gc_in_progress = 1. Yes, but the flag is not the issue here. The issue here is that while GC runs, it marks Lisp objects, which might make them look invalid to Lisp code. In addition, GC can compact strings and other objects, and if the signal hits at that moment, Lisp code could start working on an invalid string, or string whose data was moved elsewhere. But all this happens when mark_object and its subroutines have really done some non-trivial job; when you stop GC before they start, all those problems did not yet materialize. > Are you trying to argue Emacs cannot possibly enter the SIGTERM > handler between that and when GC "really starts doing its job" > (whenever that is)? No, of course not. > > And look at the variable 'args', which should be a list. Since this > > session crashed in GC, it is not safe to print Lisp objects with > > "pp" and its likes. Instead, you will have to walk the list using > > "xcar" and "xcdr", display the type of each object in the list using > > "xtype", and then display the object itself with the appropriate x* > > command, normally "xsymbol", since the list is constructed from > > function symbols. > > Can this be done for core dump files? Yes, the commands I mentioned work for core dumps as well. They just manipulate bit masks. Btw, if you want to see a better backtrace, both in C and in Lisp, remove or rename the *.elc files of the involved packages. then Emacs will run the *.el files in the interpreter, and you will see much more detail, instead of all those unhelpful exec_byte_code calls that tell nothing about what is being invoked.