On Oct 20 09:03, Ken Brown wrote:
> When trying to debug emacs in gdb, I see several threads, but it's not
> always clear who created those threads and what they're doing.  As an
> example, I attached gdb to an emacs-X11 process (running under X) shortly
> after starting it, and I obtained the backtrace appended at the end of this
> message.
> 
> I assume Thread 12 was created by gdb.

Yes, that's the debugging thread created by the OS when a debugger
connects.

Thread 11 and 10 seem to be dead threads which have been added to the
thread pool?!?

Thread 9 is a worker thread for select on a pipe.

Thread 8 and 7 are unrecognizable, I'd bet on a select call in at
least one of them.

> Thread 6 appears to be a timer thread 

Right, thread 6 is a worker thread for a timer_settime call (also 
called from setitimer, alarm, ualarm).

Thread 5 is another select on a pipe, thread 4 and 3 again not
recognizable.

> and Thread 2 appears to be a signal thread;

Right.

> I assume both of these
> were created by the Cygwin DLL.  And Thread 1 is the main thread.

Right.  Thread 2, 5, 6, 9 are Cygwin-created threads.

Threads 3, 4, 7 and 8 appear to be application-created threads.  At
least one of them is waiting in a select call, waiting for two pipe
handles, or two of them waiting for one each.  Select itself starts
threads a lot.

Threads 10 and 11 seemed to be ignorable, but I never saw threads
waiting in WaitForWorkViaWorkerFactory myself.  Cygwin does not
utilize the OS thread pools by itself, rather it implements its
own.

> I don't
> have any idea where the other threads came from.  Presumably at least one of
> them was created by Glib.
> 
> The situation is similar with emacs-w32 and emacs-nox, but with fewer threads.
> 
> In general, is there a way I can understand where all the threads come from?

There's no simple generic way to do that, afaik.

One big problem is to have all the symbols.  You should definitely
install the debuginfo packages of all potentially affected packages, not
only cygwin-debuginfo.  If you want to find out where threads are called
from the application, you might get a clue by running emacs under GDB and
set a breakpoint to pthread_create.

Unless, of course, any component starts threads by calling the Windows
function CreateThread.  There's no guarantee that Cygwin's thread
handling will catch these, even though it tries.

> My reason for asking is that we're still getting emacs bug reports on 64-bit
> Cygwin, with random crashes or assertion violations that are "impossible"
> according to the gdb backtraces. [*]  So I'm wondering whether they're
> caused by interference from other threads.
> 
> Or is there some other plausible explanation for "impossible" crashes?  This
> can't just be a result of a gdb bug, because in at least one case the
> assertion can be shown to be valid by using printf instead of gdb.

One of the headaches when porting is sometimes the ABI.  While on Linux
the first 6 arguments to a function are given in registers, on Windows
only 4 args are in registers.  This can result in bugs when calling
functions with more than 4 parameters, which are invisible on Linux, due
to the way 32 bit parameter are stored in registers on x86_64.  This
happened to us already for at least one package.

Other than that, it could be a bug in any of the affected components,
including Cygwin.  I'm sorry, but I don't even have a tang of a hunch,
even after reading the emacs bugreport entries :(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat