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#14333: 24.3.50; Emacs hangs when trying to exit Date: Thu, 09 May 2013 18:53:04 +0300 Message-ID: <83obckcfq7.fsf@gnu.org> References: <83r4hpnykn.fsf@gnu.org> <837gj9e82c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1368114849 8119 80.91.229.3 (9 May 2013 15:54:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 15:54:09 +0000 (UTC) Cc: 14333@debbugs.gnu.org To: Dani Moncayo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 09 17:54:07 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 1UaTAV-0002iT-HH for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 17:54:07 +0200 Original-Received: from localhost ([::1]:33966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaTAU-00052C-UE for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 11:54:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaTAN-000522-MG for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 11:54:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaTAM-0005pR-CC for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 11:53:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaTAM-0005pL-8V for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 11:53:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UaTAQ-0005w3-GS for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 11:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 May 2013 15:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14333 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 14333-submit@debbugs.gnu.org id=B14333.136811479822669 (code B ref 14333); Thu, 09 May 2013 15:54:02 +0000 Original-Received: (at 14333) by debbugs.gnu.org; 9 May 2013 15:53:18 +0000 Original-Received: from localhost ([127.0.0.1]:34868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaT9i-0005tZ-C0 for submit@debbugs.gnu.org; Thu, 09 May 2013 11:53:18 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:39052) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaT9f-0005tJ-LP for 14333@debbugs.gnu.org; Thu, 09 May 2013 11:53:17 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MMJ00K00G0ESP00@a-mtaout21.012.net.il> for 14333@debbugs.gnu.org; Thu, 09 May 2013 18:53:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MMJ00KIUG4HK0B0@a-mtaout21.012.net.il>; Thu, 09 May 2013 18:53:06 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:74102 Archived-At: > Date: Thu, 9 May 2013 11:09:11 +0200 > From: Dani Moncayo > Cc: 14333@debbugs.gnu.org > > So, it seems it is not possible to attach gdb to the hanged Emacs > session. Is there another way of tracking down the problem? I hope so. See below. > For example, I could add some sentences at the C level, which write > information to some log file. If this is a good idea, just send me > the patch I should apply. I don't know yet what to write and where. We need more information about the problem. I can think about 2 methods to gain more info: 1) Attach GDB before you exit Emacs, while Emacs still runs. Hopefully, it will attach cleanly. Then: (gdb) break shut_down_emacs (gdb) continue Now exit Emacs as usual. GDB will kick in and stop Emacs inside shut_down_emacs. Step through that function (with "next") and see which call doesn't return. Then try the same again in another session, but now step into the function that didn't return, and step through that, again looking for some sub-function that doesn't return. Etc., etc., until you find which system call doesn't return, or maybe some Emacs code that infloops for some reason. 2) Download and install the latest version of Process Explorer from SysInternals. Start Process Explorer and find the line showing the running Emacs (before you exit it). Right-click on that line, and select "Properties". In the window that pops up, click on the "Threads" tab. You should see several threads that belong to Emacs. Now exit Emacs. Every thread that exits should have its line highlighted by a red background. Normally, they all exit, so they all become red. I suspect that in your case, some of them will not exit. If so, click on the line of that thread, and tell what is its State as shown below the thread list. Next, click the entry of the thread that didn't exit, and push the "Stack" button below the thread list. This should pop up another window with the call stack addresses. Press "Copy All" and then paste into some file. Repeat this for every thread that did not exit. Now start GDB on the Emacs binary: gdb emacs.exe and translate the call stack addresses into source lines like this: (gdb) list *0xNNNNNNN where NNNNNNN is the address you see in the call stack after "emacs+", to which you need to add 0x1000000. For example, if you see emacs+0x19f93, type (gdb) list *0x1019f93 This should show a small number of source lines around the line that corresponds to the address. The top-most address of the form emacs+0xNNNN that you find in the call stack of each thread that didn't exit is the most important one -- it tells where that thread is stuck. Alternatively, you can use addr2line to convert addresses to source line numbers; once again, you will need to add 0x1000000 to each address displayed by the Process Explorer. I hope at least one of these 2 methods will allow us to determine why Emacs hangs.