bug#12832: 24.3.50; Emacs lockup when idle

[Eli Zaretskii]

> Date: Tue, 13 Nov 2012 16:40:29 +0000
> From: Andy Moreton <andrewjmoreton@gmail.com>
> 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 <andrewjmoreton@gmail.com>
> >> 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