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
Date: Wed, 8 Oct 2003 21:07:24 -0400
From: Christopher Faylor <cgf-rcm AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: setup hangs during postinstall
Message-ID: <20031009010723.GA5593@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT GSO DOT 4 DOT 56 DOT 0310081405080 DOT 2767 AT eos>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.56.0310081405080.2767@eos>
User-Agent: Mutt/1.4.1i

On Wed, Oct 08, 2003 at 02:12:34PM -0500, Brian Ford wrote:
>The hand decoded trace (The same one as before.  I still had gdb up.)
>is below.

Wow, that was a lot of work.  Thanks for doing this.

>>That's the only way I know of to deal with this.  If gcc produced dwarf2
>>output, we could use the CFI to get more accurate information about the
>>stack frame but that's not going to happen anytime soon.
>>
>Was that a hint for me :).

Not really.  I actually started typing the above and got a few sentences
in when something tickled my memory that you were working on this.

>Getting gcc to product dwarf2 output is easy.  Getting the resulting
>executable to run with the dwarf2 sections is the hard part.  It
>(dwarf2) needs a section relative relocation in gas/ld/bfd like I said
>before.  Know anyone who wants to help?  :D

Unfortunately, not.  I've been asking various people to do this for years.

>>>I included all three thread backtraces just in case anyone can see
>>>anything.  Let me know if have any better idea about how to track this
>>>down.
>>
>>The trace from thread 2 is what I would expect.  Thread 1 is obviously
>>waiting for something but I don't know what without more stack info.
>>
>
>I'll do thread 3 too if you think it is relevent.
>
>(gdb) info threads
>  3 thread 1920.0x4f0  0x77f75a59 in ntdll!DbgUiConnectToDbg ()
>   from /cygdrive/c/WINDOWS/System32/ntdll.dll
>  2 thread 1920.0x6e4  0x7ffe0304 in ?? ()
>* 1 thread 1920.0x760  0x7ffe0304 in ?? ()
>(gdb) thread 1
>[Switching to thread 1 (thread 1920.0x760)]#0  0x7ffe0304 in ?? ()
>(gdb) bt
>#0  0x7ffe0304 in ?? ()
>#1  0x77f5c524 in ntdll!ZwWaitForMultipleObjects ()
>   from /cygdrive/c/WINDOWS/System32/ntdll.dll
>#2  0x77e75ee0 in WaitForMultipleObjectsEx ()
>   from /cygdrive/c/WINDOWS/system32/kernel32.dll
>#3  0x610901e9 in muto::acquire(unsigned long) (../../../../cygwin/winsup/cygwin/sync.cc:75)
>#4  0x6108b587 is in WFMO (../../../../cygwin/winsup/cygwin/sigproc.cc:1248)
>#5  0x61090410 is in close_all_files() (../../../../cygwin/winsup/cygwin/syscalls.cc:10
>#6  0x6108d81f is in spawn_guts(char const*, char const* const*, char const* const*, int) (../../../../cygwin/winsup/cygwin/spawn.cc:847)
>#7  0x6108c830 is in do_cleanup(void*) (../../../../cygwin/winsup/cygwin/spawn.cc:336)
>(gdb) thread 2

So, if I can believe this trace, it looks like cygwin is hanging waiting for
a lock while exiting.  I don't see how it's possible to be waiting for
a lock unless cygpath was a multi-threaded app or if the signal thread
grabbed the lock and didn't give it up, neither of which should be the
case.

So, color me puzzled.  I will continue to ponder this, though.  I haven't
had a shower yet.  That's where most of my inspiration hits me...

...Well, it's close to the shower, anyway...

cgf

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