RE: FW: cygwin-1.dll long-time bug

RE: FW: cygwin-1.dll long-time bug

[Williams, Gerald S (Jerry)]

Eric Blake wrote:
> According to Dave Korn on 4/18/2006 12:38 PM:
>> [...] and it's probably not something that gets a whole load
>> of testing in microsoft's QA dept.... ;)  
>
> They have one?  What are the job qualifications to become a member of
> that dept, I wonder?  I bet even a hippo could apply...

I think you have it all wrong--they must have the best QA
department in the world to get their software to the point
it's at. It's obvious that the source code is written by a
boatload of demented monkeys. The hippos are only used to
keep the monkeys under control.

gsw

RE: FW: cygwin-1.dll long-time bug

[Igor Peshansky]

On Wed, 19 Apr 2006, Williams, Gerald S (Jerry) wrote:

> Eric Blake wrote:
> > According to Dave Korn on 4/18/2006 12:38 PM:
> >> [...] and it's probably not something that gets a whole load
> >> of testing in microsoft's QA dept.... ;)
> >
> > They have one?  What are the job qualifications to become a member of
> > that dept, I wonder?  I bet even a hippo could apply...
>
> I think you have it all wrong--they must have the best QA
> department in the world to get their software to the point
> it's at. It's obvious that the source code is written by a
> boatload of demented monkeys. The hippos are only used to
> keep the monkeys under control.

That means they need to drop the hippos on the monkeys, not on the
software...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

RE: FW: cygwin-1.dll long-time bug

[Dave Korn]

On 19 April 2006 14:47, Williams, Gerald S (Jerry) wrote:

> Eric Blake wrote:
>> According to Dave Korn on 4/18/2006 12:38 PM:
>>> [...] and it's probably not something that gets a whole load
>>> of testing in microsoft's QA dept.... ;)
>> 
>> They have one?  What are the job qualifications to become a member of
>> that dept, I wonder?  I bet even a hippo could apply...
> 
> I think you have it all wrong--they must have the best QA
> department in the world to get their software to the point
> it's at. It's obvious that the source code is written by a
> boatload of demented monkeys. The hippos are only used to
> keep the monkeys under control.
> 
> gsw


  I object!  Monkeys make *great* coders - demented ones even more so!

  No, the real problem with Microsoft is not the demented monkeys.  It's all
the skunks and weasels in high level management.

  Oh, and that psychotic gorilla leaping around beating his chest don't help
none, neither.  Leave the damn chair alone, already!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

FW: cygwin-1.dll long-time bug

[Dave Korn]

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!

http://www.cygwin.com/ml/cygwin/2004-05/msg00694.html

  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

http://www.anticracking.sk/EliCZ/bugs/WinBugs.htm

and there's a thread at 

http://www.sysinternals.com/Forum/forum_posts.asp?TID=126&PN=1

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.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: FW: cygwin-1.dll long-time bug

[Christopher Faylor]

On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
>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."

So, rather than saying "I wonder why Cygwin would hang when a thread is
injected?" the conclusion is that "Cygwin behavior which is incompatible
with the Windows API" and the fix is to "thread injection gracefully".

I don't see what more there is to say on the subject.  Clearly with just
a little more grace, Cygwin's problems would be solved.

cgf

RE: FW: cygwin-1.dll long-time bug

[Dave Korn]

On 18 April 2006 19:26, Christopher Faylor wrote:

> On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
>> 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."
> 
> So, rather than saying "I wonder why Cygwin would hang when a thread is
> injected?" the conclusion is that "Cygwin behavior which is incompatible
> with the Windows API" and the fix is to "thread injection gracefully".
> 
> I don't see what more there is to say on the subject.  Clearly with just
> a little more grace, Cygwin's problems would be solved.
> 
> cgf


  Well, I think it's reasonable enough to say that cygwin does things that are
pushing the envelope of what's documented to work in relation to how we handle
forking and process startup.  After all we just had that lockup caused by the
fact that you can't even call GetModuleName[*] from DllMain safely.  Things
happen in an unusual order in cygwin processes and threads, and it's probably
not something that gets a whole load of testing in microsoft's QA dept.... ;)


    cheers,
      DaveK

[*] - or whatever it was, I haven't been and looked up the original thread
yet.
-- 
Can't think of a witty .sigline today....

RE: FW: cygwin-1.dll long-time bug

[Gary R. Van Sickle]

> From: Dave Korn
> Sent: Tuesday, April 18, 2006 1:39 PM
> To: 'tricksy codes'
> Subject: RE: FW: cygwin-1.dll long-time bug
> 
> On 18 April 2006 19:26, Christopher Faylor wrote:
> 
> > On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
> >> 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."
> > 
> > So, rather than saying "I wonder why Cygwin would hang when 
> a thread 
> > is injected?" the conclusion is that "Cygwin behavior which is 
> > incompatible with the Windows API" and the fix is to 
> "thread injection gracefully".
> > 
> > I don't see what more there is to say on the subject.  Clearly with 
> > just a little more grace, Cygwin's problems would be solved.
> > 
> > cgf
> 
> 
>   Well, I think it's reasonable enough to say that cygwin 
> does things that are pushing the envelope of what's 
> documented to work in relation to how we handle forking and 
> process startup.  After all we just had that lockup caused by 
> the fact that you can't even call GetModuleName[*] from 
> DllMain safely.  Things happen in an unusual order in cygwin 
> processes and threads, and it's probably not something that 
> gets a whole load of testing in microsoft's QA dept.... ;)
> 
> 
>     cheers,
>       DaveK
> 

WHOAH WHOAH WHOAH there Korns, don't take personal offense!  Sheesh!  It's
getting to be a regular minefield in here!

-- 
Gary R. Van Sickle
 

Re: FW: cygwin-1.dll long-time bug

[Christopher Faylor]

On Tue, Apr 18, 2006 at 09:26:43PM -0500, Gary R. Van Sickle wrote:
>> From: Dave Korn
>> Sent: Tuesday, April 18, 2006 1:39 PM
>> To: 'tricksy codes'
>> Subject: RE: FW: cygwin-1.dll long-time bug
>> 
>> On 18 April 2006 19:26, Christopher Faylor wrote:
>> 
>> > On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
>> >> 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."
>> > 
>> > So, rather than saying "I wonder why Cygwin would hang when 
>> a thread 
>> > is injected?" the conclusion is that "Cygwin behavior which is 
>> > incompatible with the Windows API" and the fix is to 
>> "thread injection gracefully".
>> > 
>> > I don't see what more there is to say on the subject.  Clearly with 
>> > just a little more grace, Cygwin's problems would be solved.
>> 
>>   Well, I think it's reasonable enough to say that cygwin 
>> does things that are pushing the envelope of what's 
>> documented to work in relation to how we handle forking and 
>> process startup.  After all we just had that lockup caused by 
>> the fact that you can't even call GetModuleName[*] from 
>> DllMain safely.  Things happen in an unusual order in cygwin 
>> processes and threads, and it's probably not something that 
>> gets a whole load of testing in microsoft's QA dept.... ;)
>> 
>
>WHOAH WHOAH WHOAH there Korns, don't take personal offense!  Sheesh!  It's
>getting to be a regular minefield in here!

It sounds like an apology is due here since if *Gary* could possibly
misconstrue something I said (an even I would have heretofore considered
almost impossible), then surely it is likely that Dave Korn, who is only
mortal, could also.

I had read Dave's response as just an objective counter to my observation
about handling "thread injection gracefully".  Now I see that he was
actually highly offended.

So, here goes:

Dave, I didn't realize that you and Mark Russinovich were so close as
for me to offend you by reacting to his statement.

My sincere apologies.  I always value your technical contributions.  You
are one of those rare individuals who contribute humor, technical
understanding, and even the occasional patch.  I certainly would not
want you to go away mad because of my thoughtlessness.

To clarify what I was saying: I was expressing frustration that this
notable who may understand NT internals better than most other people on
the planet would resort to such vague terms.  When I saw that you'd
quoted a message from Mark which talked about Cygwin I was disappointed
that *he* (not you) didn't offer any ideas or suggestions about what
could be wrong.  In my frustration, I lashed out at you with stinging
and inappropriate words that I now know truly wounded you.  I am wracked
with guilt over my actions and vow to treat you better in the future.

Sincerely,
Christopher G. Faylor

RE: FW: cygwin-1.dll long-time bug

[Dave Korn]

On 19 April 2006 18:07, Christopher Faylor wrote:

> On Tue, Apr 18, 2006 at 09:26:43PM -0500, Gary R. Van Sickle wrote:

>>> On 18 April 2006 19:26, Christopher Faylor wrote:
>>> 
>>>> On Tue, Apr 18, 2006 at 07:13:38PM +0100, Dave Korn wrote:
>>>>> 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."
>>>> 
>>>> So, rather than saying "I wonder why Cygwin would hang when a thread
>>>> is injected?" the conclusion is that "Cygwin behavior which is
>>>> incompatible with the Windows API" and the fix is to "thread injection
>>>> gracefully". 
>>>> 
>>>> I don't see what more there is to say on the subject.  Clearly with
>>>> just a little more grace, Cygwin's problems would be solved.
>>> 
>>>   Well, I think it's reasonable enough to say that cygwin
>>> does things that are pushing the envelope of what's
>>> documented to work in relation to how we handle forking and
>>> process startup.  After all we just had that lockup caused by
>>> the fact that you can't even call GetModuleName[*] from
>>> DllMain safely.  Things happen in an unusual order in cygwin
>>> processes and threads, and it's probably not something that
>>> gets a whole load of testing in microsoft's QA dept.... ;)
>>> 
>> 
>> WHOAH WHOAH WHOAH there Korns, don't take personal offense!  

  Gary, you clearly need to get your eyes tested.  Can't you see the smiley?
Don't make me use html just because your aged rheumy eyes need everything
written in <H1> BIG LETTERS </H1>!

>>Sheesh!  It's
>> getting to be a regular minefield in here!

  Umm, no, Gary, those things the hippos leave lying around aren't mines.  As
you should already know, since you just stepped in one, yet still seem to have
both legs.

> It sounds like an apology is due here since if *Gary* could possibly
> misconstrue something I said (an even I would have heretofore considered
> almost impossible), then surely it is likely that Dave Korn, who is only
> mortal, could also.
> 
> I had read Dave's response as just an objective counter to my observation
> about handling "thread injection gracefully".  Now I see that he was
> actually highly offended.

  AUGH!  Somebody's taking GVRS seriously!?!  My brain's exploding!  Which way
to the asylum?????

> So, here goes:
> 
> Dave, I didn't realize that you and Mark Russinovich were so close as
> for me to offend you by reacting to his statement.

  I am deeply offended by your assumption that me and Mark Russinovich are so
close!

> My sincere apologies.  

  Sincere apologies?!  Ugh!  Ptui!  Those are my /very/ least favourite kind!

> I always value your technical contributions.  You
> are one of those rare individuals who contribute humor, technical
> understanding, and even the occasional patch.  I certainly would not
> want you to go away mad because of my thoughtlessness.

  Damn, you're just getting ruder and ruder!  Can't you stop digging before it
gets really worse?

> To clarify what I was saying: I was expressing frustration that this
> notable who may understand NT internals better than most other people on
> the planet would resort to such vague terms.  When I saw that you'd
> quoted a message from Mark which talked about Cygwin I was disappointed
> that *he* (not you) didn't offer any ideas or suggestions about what
> could be wrong.  In my frustration, I lashed out at you with stinging
> and inappropriate words that I now know truly wounded you.  I am wracked
> with guilt over my actions and vow to treat you better in the future.

  That's the most offensive thing I've ever read in my entire life and I am
*sooo* upset that I'm going outside right now and drown a cute fluffy little
kitten.

  AND IT'S ALL YOUR FAULT, YA HEAR ME????  EH????!?  EH???  DO YOU?

> Sincerely,

  <feh>  Yeh, right!

> Christopher G. Faylor

  I KNEW THAT ALREADY!  WHY ARE YOU TELLING ME STUFF I ALREADY KNOW!?!:?
CYGWIN FIXED!  YOU BREAK IT NOW!!!1!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: FW: cygwin-1.dll long-time bug

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Dave Korn on 4/18/2006 12:38 PM:
> 
>   Well, I think it's reasonable enough to say that cygwin does things that are
> pushing the envelope of what's documented to work in relation to how we handle
> forking and process startup.  After all we just had that lockup caused by the
> fact that you can't even call GetModuleName[*] from DllMain safely.  Things
> happen in an unusual order in cygwin processes and threads, and it's probably
> not something that gets a whole load of testing in microsoft's QA dept.... ;)

They have one?  What are the job qualifications to become a member of that
dept, I wonder?  I bet even a hippo could apply...

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFERbIR84KuGfSFAYARAp2kAJ0Y+cRPD4HKcenYj/LkQLiwI7/PHgCgw249
fWsG0xVksjucwkn3aZJhbUM=
=sfVh
-----END PGP SIGNATURE-----

RE: FW: cygwin-1.dll long-time bug

[Dave Korn]

On 19 April 2006 04:44, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Dave Korn on 4/18/2006 12:38 PM:
>> 
>>   Well, I think it's reasonable enough to say that cygwin does things that
>> are pushing the envelope of what's documented to work in relation to how
>> we handle forking and process startup.  After all we just had that lockup
>> caused by the fact that you can't even call GetModuleName[*] from DllMain
>> safely.  Things happen in an unusual order in cygwin processes and
>> threads, and it's probably not something that gets a whole load of testing
>> in microsoft's QA dept.... ;) 
> 
> They have one?  What are the job qualifications to become a member of that
> dept, I wonder?  I bet even a hippo could apply...
> 

  Yes, actually!  Most of their testing is done by dropping hippos on software
and seeing what happens.  Usually it breaks.






         .





         .





         .





         .


  Then they ship it!



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: FW: cygwin-1.dll long-time bug

[Igor Peshansky]

On Wed, 19 Apr 2006, Dave Korn wrote:

> On 19 April 2006 04:44, Eric Blake wrote:
>
> > According to Dave Korn on 4/18/2006 12:38 PM:
> >
> >> [snip]
> >> in microsoft's QA dept.... ;)
> >
> > They have one?  What are the job qualifications to become a member of that
> > dept, I wonder?  I bet even a hippo could apply...
>
>   Yes, actually!  Most of their testing is done by dropping hippos on
> software and seeing what happens.  Usually it breaks.
>   Then they ship it!

This reminds me of the actual testing DEC did for PDP-8 and PDP-11
machines: they dropped a machine on the concrete floor from a height of
precisely 2 meters while it was performing some computation.  If it
continued working at that point and produced correct results, they shipped
it.  Eerie, isn't it?

Oh, and in the words of ESR: "software is largely a service industry
operating under the persistent but unfounded delusion that it is a
manufacturing industry".  Just seemed relevant here, somehow... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

RE: FW: cygwin-1.dll long-time bug

[Dave Korn]

On 19 April 2006 13:59, Igor Peshansky wrote:

> On Wed, 19 Apr 2006, Dave Korn wrote:
> 
>> On 19 April 2006 04:44, Eric Blake wrote:
>> 
>>> According to Dave Korn on 4/18/2006 12:38 PM:
>>> 
>>>> [snip]
>>>> in microsoft's QA dept.... ;)
>>> 
>>> They have one?  What are the job qualifications to become a member of that
>>> dept, I wonder?  I bet even a hippo could apply...
>> 
>>   Yes, actually!  Most of their testing is done by dropping hippos on
>> software and seeing what happens.  Usually it breaks.
>>   Then they ship it!
> 
> This reminds me of the actual testing DEC did for PDP-8 and PDP-11
> machines: they dropped a machine on the concrete floor from a height of
> precisely 2 meters while it was performing some computation.  If it
> continued working at that point and produced correct results, they shipped
> it.  Eerie, isn't it?

  That's a great technique, I can highly recommend it.  Back when I was in
school, we used to test the RM380Zs by dropping them out of first-floor
windows.

  Usually they broke the concrete when they hit, not themselves.

> Oh, and in the words of ESR: "software is largely a service industry
> operating under the persistent but unfounded delusion that it is a
> manufacturing industry".  Just seemed relevant here, somehow... :-)

  Yeh, but then again, also in the words of ESR: "I will find a way to make
you regret it.  Watch your step"

 ;)

http://geekz.co.uk/lovesraymond/archive/bruce-perens-dead


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: FW: cygwin-1.dll long-time bug

[Ludovic Drolez]

Dave Korn <dave.korn <at> artimi.com> writes: 
> 
> "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.
> 
>     cheers,
>       DaveK

Hello,

I'm currently trying to debug something which seems to show the same symptoms as
the processxp one: When we try to update (with windows update) some multimedia
dlls on windows (mediaplayer fixes, itunes, etc), cygrunsrv.exe hogs 75% of the
cpu, csrss.exe 25% and the update freezes. Maybe the update process tries to
list the threads in a strange way ?

But I'm not sure since I do not seen any ref to
'RtlQueryProcessDebugInformation' in the gdb bt:

http://www.cygwin.com/ml/cygwin/2006-04/msg00856.html

Any ideas if the bugs are related ?
(and do you have a tool to find which thread is looping?)

Cheers,

   Ludovic.