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/
