Christopher Faylor wrote: >Brian Ford wrote: >>It looks to me like the stack is corrupted, but I'm probably just being >>naive. > >This is unfortunately a standard stack for a frame-pointerless function >(probably *WaitForMultipleWindowsEx). The laborious way to find the >caller is to do something like a: > >x/200x $esp > >and then look for 0x6100xxxx addresses in the output, decoding them with >something like: > >l *0x61041234 > >There will be some garbage on the stack so some 0x6100xxxx addresses will >not be useful. > Ok. Thanks.
The hand decoded trace (The same one as before. I still had gdb up.) is below. >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 :). 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 >>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 [Switching to thread 2 (thread 1920.0x6e4)]#0 0x7ffe0304 in ?? () (gdb) bt #0 0x7ffe0304 in ?? () #1 0x77f5bfb4 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/System32/ntdll.dll #2 0x77e7abbd in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108ad36 is in wait_sig(void*) (../../../../cygwin/winsup/cygwin/sigproc.cc:1089) #4 0x610a0ddb is in pthread_key::set(void const*) (../../../../cygwin/winsup/cygwin/thread.cc:1384) #5 0x61002d00 is in cygthread::stub(void*) (../../../../cygwin/winsup/cygwin/cygthread.cc:32) #6 0x61024a70 is in handle_exceptions (../../../../cygwin/winsup/cygwin/exceptions.cc:420) #7 0x61002d00 is in cygthread::stub(void*) (../../../../cygwin/winsup/cygwin/cygthread.cc:32) (gdb) thread 3 [Switching to thread 3 (thread 1920.0x4f0)]#0 0x77f75a59 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/System32/ntdll.dll (gdb) bt #0 0x77f75a59 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/System32/ntdll.dll #1 0x77f5f31f in ntdll!KiUserCallbackDispatcher () from /cygdrive/c/WINDOWS/System32/ntdll.dll #2 0x00000005 in ?? () #3 0x00000004 in ?? () #4 0x00000001 in ?? () #5 0x003fffd0 in ?? () #6 0x85e0d020 in ?? () #7 0xffffffff in ?? () #8 0x77fa88f0 in wcstombs () from /cygdrive/c/WINDOWS/System32/ntdll.dll (gdb) -- 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/
