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#12832: 24.3.50; Emacs lockup when idle Date: Tue, 13 Nov 2012 19:20:07 +0200 Message-ID: <83d2zhv2rc.fsf@gnu.org> References: <838vac12kn.fsf@gnu.org> <509BFAE7.8020205@gmail.com> <83liebyu9t.fsf@gnu.org> <509CDF7F.2000409@gmail.com> <83ip9fyqmy.fsf@gnu.org> <83390izlxm.fsf@gnu.org> <509D4DAC.1060901@gmail.com> <83pq3hvet0.fsf@gnu.org> <509BAC2E.2000702@gmail.com> <80r4nxsl1s.fsf@somewhere.org> <83lie5vbot.fsf@gnu.org> <50A2585A.3050008@gmail.com> <83ip99v8h5.fsf@gnu.org> <50A26E9E.4020405@gmail.com> <83fw4dv4uh.fsf@gnu.org> <50A277FD.4030200@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1352827245 3109 80.91.229.3 (13 Nov 2012 17:20:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2012 17:20:45 +0000 (UTC) Cc: fni@missioncriticalit.com, 12832@debbugs.gnu.org To: Andy Moreton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 13 18:20:55 2012 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 1TYKAL-0006Hv-QY for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Nov 2012 18:20:50 +0100 Original-Received: from localhost ([::1]:44276 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYKAC-0006ZB-3P for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Nov 2012 12:20:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYKA6-0006YP-MY for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 12:20:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYKA3-0002Am-K8 for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 12:20:34 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYKA3-0002Ag-GS for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 12:20:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TYKAX-0003d8-TK for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 12:21:01 -0500 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: Tue, 13 Nov 2012 17:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12832 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 12832-submit@debbugs.gnu.org id=B12832.135282723613923 (code B ref 12832); Tue, 13 Nov 2012 17:21:01 +0000 Original-Received: (at 12832) by debbugs.gnu.org; 13 Nov 2012 17:20:36 +0000 Original-Received: from localhost ([127.0.0.1]:39025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYKA3-0003cP-9q for submit@debbugs.gnu.org; Tue, 13 Nov 2012 12:20:36 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:39454) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYK9w-0003cA-4V for 12832@debbugs.gnu.org; Tue, 13 Nov 2012 12:20:29 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDF00H00S23H500@a-mtaout20.012.net.il> for 12832@debbugs.gnu.org; Tue, 13 Nov 2012 19:19:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDF00GMES50VHD0@a-mtaout20.012.net.il>; Tue, 13 Nov 2012 19:19:49 +0200 (IST) In-reply-to: <50A277FD.4030200@gmail.com> X-012-Sender: halo1@inter.net.il X-Spam-Score: 1.5 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 1.5 (+) 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:66882 Archived-At: > Date: Tue, 13 Nov 2012 16:40:29 +0000 > From: Andy Moreton > CC: dmoncayo@gmail.com, fni@missioncriticalit.com, 12832@debbugs.gnu.org > > On 13/11/2012 16:35, Eli Zaretskii wrote: > >> Date: Tue, 13 Nov 2012 16:00:30 +0000 > >> From: Andy Moreton > >> CC: dmoncayo@gmail.com, fni@missioncriticalit.com, 12832@debbugs.gnu.org > >> > >> The fact that thread 236140 is at ThreadStartRoutine makes me wonder if this > >> is related to the perils of DllMain (i.e. the loader lock). > > > > Sorry, I don't follow. Can you say more about this problem, or point > > me to some accessible documentation about it? > > The DllMain notifications for process and thread create/destroy are called > with the (system internal) loader lock held. This means that anything called > from these routines should not use locks, or deadlock is possible. So I was > wondering if the thread manipulation for timer handling is interacting with > those mechanisms. Thanks for the explanation. > Of course I don't know nearly enough about Win32 to actually say much useful > here, so the actual problem is probably something else entirely. Don't assume I know more than you do ;-) Anyway, I actually don't understand why some thread is at ThreadStartRoutine, if that fact really means that a thread is being created. The timer thread is created during startup, and is not shut down until Emacs shuts down. And we don't create any other threads in the middle of a session (unless the user invokes profiler). So the only way I can understand this ThreadStartRoutine business is that somehow the timer thread exited due to an error (look for a line saying "return 2;" in timer_loop), and then the next time Emacs sets up the 2-sec atimer, a new thread will be started. So could you please set a breakpoint at line 575 in w32proc.c, which is this: /* Start a new thread. */ itimer->terminate = 0; itimer->type = which; <<<<<<<<<<<<<<<<<<<<<<<<<<< run Emacs under GDB, and see if this breakpoint breaks more than once when you run Emacs as usual? It should break one time during startup, and never thereafter. To make sure you don't disrupt the timers, define commands for this breakpoint that simply continue, like this: (gdb) break w32proc.c:575 (gdb) commands > continue > end