This is the mail archive of the
mailing list for the cygwin project.
FW: cygwin-1.dll long-time bug
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'mysteries of the ancients'" <cygwin-talk at cygwin dot com>
- Date: Tue, 18 Apr 2006 19:13:38 +0100
- Subject: FW: cygwin-1.dll long-time bug
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
On 18 April 2006 17:23, Dave Korn wrote:
[ TITTTLing this thread because I'm largely just thinking out loud to myself, and because it's highly speculative and pretty esoteric. If I get the problem solved I'll post a summary on the main list. In the meantime this thread will at least archive anything I turn up. ]
> Ah, I just found something out.
Well, I deduce that RtlpQueryProcessDebugInformationRemote is the entry point for a remote thread created in the target thread's address space to gather debug info, and that therefore there's probably a corresponding RtlQueryProcessDebugInformation function being called in the querying process, so I google for that.
LOL, it turns out I already found this all out once before but forgot!
So, there's a certain kind of RtlQueryProcessDebugInformation call that causes this problem. I also found some ideas about what could be causing the problem at
and there's a thread at
where Mark Russinovich says
"As for the issues looking at threads, the problem is a Cygwin behavior that's incompatible with the Windows API, RtlQueryProcessDebugInformation, that Process Explorer uses to obtain the list of modules loaded into a process. That API injects a thread into the remote process to query the loader data structures. The target process DLLs get a DLL_THREAD_ATTACH notification, which causes some Cygwin DLL thread to hang and the RtlQueryProcessDebugInformation to never return."
This gives me even more to go on... we may be able to do something about this.
Can't think of a witty .sigline today....