Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
X-Authentication-Warning:	eos.vss.fsi.com: ford owned process doing -bs
Date:	Tue, 14 Oct 2003 14:13:44 -0500 (CDT)
From:	Brian Ford <ford AT vss DOT fsi DOT com>
X-X-Sender:	ford AT eos
To:	cygwin AT cygwin DOT com
Subject:	Re: setup hangs during postinstall
In-Reply-To:	<20031014184253.GH16944@redhat.com>
Message-ID:	<Pine.GSO.4.56.0310141400340.823@eos>
References:	<Pine DOT GSO DOT 4 DOT 56 DOT 0310131207550 DOT 791 AT eos> <20031014025019 DOT GA31727 AT redhat DOT com>
	<Pine DOT GSO DOT 4 DOT 56 DOT 0310141018270 DOT 791 AT eos> <20031014165522 DOT GF16944 AT redhat DOT com>
	<Pine DOT GSO DOT 4 DOT 56 DOT 0310141310200 DOT 823 AT eos> <20031014184253 DOT GH16944 AT redhat DOT com>
MIME-Version:	1.0

On Tue, 14 Oct 2003, Christopher Faylor wrote:

> Ok, so it is hanging in process initialization.  Since it is single
> threaded it can't be attached to.  I've run into this from time to time.
> It is really hard to debug.  Maybe adding a small_printf in init.cc will
> show what's going on.
>
Will try soon.

> Igor's theory about DLLs might also be the culprit here.  I wonder if
> the PATH is different when run via the desktop and a different version
> of MSVCRT.DLL is being pulled in or something.
>
I'll use his test program soon too, but...

> I know this is acting a lot but would you be willing to use the
> SysInternals "Process Explorer" process to see if you can see anything
> funny about the DLLs that are loaded in the hung cygpath?
>
> http://sysinternals.com/ntw2k/freeware/procexp.shtml
>
Always happy to learn about good tools. :)

> Or, actually anyone who's experiencing the problem could provide this
> info.  It would be interesting to see if the DLLs that a process are
> using look "funny" where "funny" would mean coming from a non system
> directory.
>
I don't think the DLLs are the issue, but maybe.

When using the tool above, and looking at process properties->threads for
cygpath, it shows two threads.  One's state is Wait:Executive, the
other's is Wait:UserInput (both in NTDLL.DLL).

Sure enough, changing my test to

#!/bin/bash

FOO=`cygpath -S < /dev/null`

does not hang.

I've seen behavior like this before with one of our apps all the way back
to pre 1.3.22 days, but I never got a chance to debug it.  We already
launched it from a script, and it required no user input, so I just did
the above.

I'll keep digging to see if I can figure out why it is looking for user
input.

BTW, when viewing cygpath's handles, I see two WinStation ones.  Just
wondering if that means anything given the recent xemacs issues.  I think
I have your patch for that in my Cygwin DLL, though.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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/

- Raw text -