X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: "'Cygwin List'" <cygwin AT cygwin DOT com>
Subject: RE: Hanging at GetModuleFileName in inside_kernel function
Date: Tue, 21 Feb 2006 19:31:54 -0000
Message-ID: <00fc01c6371d$789be620$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <F94EE64F-3B3C-4DBE-9EB3-123223947719@rehley.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 21 February 2006 19:06, Peter Rehley wrote:

> Hi,
> 
> Well, for my particular hang issue cygwin is hanging inside the
> inside_kernel function on the GetModuleFileName call.  I tracked this
> down by adding debug statements (strace.prntf) until I got to the
> point where the debug print before GetModuleFileName would appear and
> the ones after it didn't. This is consistent.  Each hang is happening
> at this spot.
> 
> However, this doesn't explain what is happening, but only where.
> 
> I also observed that the times it hung were the only times
> inside_kernel was actually called.
> 
> I'm still trying to get more information.
> Peter
> 
> p.s. using cygwin snapshot 1.5.19-20060205.


  http://cygwin.com/acronyms#PPAST.

  Seriously.  Nobody can debug your code by ESP or remote control.  We can't
even be sure that what you report is correct if we can't reproduce it.  If you
don't show us your code, we don't even know if you've literally bracketed the
GetModuleFileName call with debug prints or if you've just placed one before
and one after the if...else if .. ladder, in which case maybe it's
strncasematch going wrong.  How do you know it hung in the function, rather
than returning from the function and then going wrong, just as a for-instance?
How do you know it's really hung, rather than taking a long time to time-out
querying a no-longer-present network drive or something like that?  How do we
know whether something earlier in your code hasn't trashed the contents of
memory so that GetModuleFileName goes off into lala-land?

  This is why posting a testcase is worthwhile, and a report that says "Umm it
don't work" is no use at all.  What, were you really expecting someone to pipe
up with "Oh, GetModuleFileName just doesn't work, that's well known"?

  I mean, ultimately, either Cygwin is calling the function correctly with
valid parameters, in which case it's a bug in windows, or it isn't, in which
case the bug is in cygwin.  You should have used some %-specifiers in those
printfs to dump the values of some of the variables, then you might have some
information to go on.  Or run the whole thing under a debugger and /see/ where
it actually goes.


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


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/