Mail Archives: cygwin/2003/10/08/21:07:43
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/
- Raw text -