On Oct 20 18:43, Corinna Vinschen wrote: > 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. > [...] > > 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.
Btw., I don't know if that helps, but the function names of native Windows functions given in the GDB backtrace may be off because GDB doesn't have access to the Windows DLL symbol tables. If you want to analyze the stacks from that side, you should install WinDbg(*) and the symbol files for your OS(**). If you start the process from WinDbg, you can better see the Windows functions called from these threads, while not getting any info about the functions from inside the application or the Cygwin DLLs. HTH, Corinna (*) http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx (**) http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpqlKMK9_Vw6.pgp
Description: PGP signature
