Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/