Stuck on threading

[Mike Hearn]

Hi,

I'm a bit stuck. I have a DLL that does a FindWindow on DLL attach, and
as part of that it does a GetWindowText which tries to send a message to
another thread, using send_inter_thread_message. Other threads then
attempt to load a DLL and the loader section prompty deadlocks.

In gdb, if I attach at this point I can see a nice backtrace of the
thread waiting for the reply to its WM_GETTEXT message, along with the
thread ID. I'd quite like to see what the thread it sent the message to
is doing, but for some reason in gdb "info threads" doesn't do anything
and "thread 18" says, thread ID not known, despite it clearly being
there in the backtrace:

#5  0x40abd0cf in send_inter_thread_message (dest_tid=18,
info=0x4072187c, res_ptr=0x40721874)
    at message.c:1719

So, I'm wondering if this is due to the funny games Wine plays with
threads, I'm on a standard glibc 2.2 system by the way. For some reason
I can't use winedbg because it stops with a load of exceptions inside
the DLL that seem to be red herrings.

Is there any way of switching to a wine thread using gdb to get a
backtrace? Is there a sneakier approach I can use to find out why thread
18 has apparently deadlocked? There is probably a race condition here -
this program will start some times but not others :(

Has anybody got any tips on how to debug this sort of thing?
thanks -mike

[Alexandre Julliard]

Mike Hearn  writes:
> Is there any way of switching to a wine thread using gdb to get a
> backtrace? Is there a sneakier approach I can use to find out why thread
> 18 has apparently deadlocked? There is probably a race condition here -
> this program will start some times but not others :(

You can attach to a specific thread with gdb, but you have to specify
its unix pid, you can't use the wine thread id of course, gdb doesn't
know about that. You can see the unix pid of a thread with +server, or
simply attach to each thread until you find the right one...

[Mike Hearn]

Thanks, later today I figured out that you can start winedbg and then
use a wine process id to attach - I was trying to attach using unix pids
and was wondering why it didn't work. The winedbg help screen seems a
little out of date, it doesn't show you that the bt command accepts a
tid as a parameter for instance, and I can't see any way to switch the
current thread, despite the docs mentioning such a concept. I think I'll
have a dig through the code tomorrow and try and improve the help screen
a bit.

Oh and in case anybody has seen something similar before, the app seems
to be freezing when iterating the window list using FindWindow during
DLL attach. Figuring out thread deadlocks seems to be a bit of a black
art....

thanks -mike

On Tue, 2003-04-08 at 18:32, Alexandre Julliard wrote:
> Mike Hearn  writes:
> > Is there any way of switching to a wine thread using gdb to get a
> > backtrace? Is there a sneakier approach I can use to find out why thread
> > 18 has apparently deadlocked? There is probably a race condition here -
> > this program will start some times but not others :(
>
> You can attach to a specific thread with gdb, but you have to specify
> its unix pid, you can't use the wine thread id of course, gdb doesn't
> know about that. You can see the unix pid of a thread with +server, or
> simply attach to each thread until you find the right one...