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