This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Threads

On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
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

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.

Thanks, I'll give that a try.

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.

Am I right in thinking this can only be an issue if the source includes assembler code?


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]