Hanging at GetModuleFileName in inside_kernel function

Peter Rehley peter@rehley.net
Fri Feb 24 00:34:00 GMT 2006 

On Feb 23, 2006, at 10:13 AM, Dave Korn wrote:

> On 23 February 2006 16:20, Peter Rehley wrote:
>
>> Yeah, I saw that change, and I tried yesterdays snapshot but it still
>> hung.  I also did some more googling and found that someone submitted
>> a patch a few years ago.  The patch checked to see if it was inside
>> the ntdll.dll by looking at the handle.
>> http://www.cygwin.com/ml/cygwin-patches/2003-q2/msg00004.html
>>
>> I found this google too.
>> http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx
>>
>> I'm going to try that patch today and see what happens.  Christopher
>> didn't apply it because it was a bandage and didn't really fix the
>> bigger problem.

I tried putting the patch in place, and it stopped hanging at the  
place I reported.  I had print statements to verify that it went  
through the section.  However, the program still hung at some point.   
I tracked down a couple of other GMFN calls that used non-null  
handles and tried using the technique that the patch had.

The one at dll_list::alloc caused nothing to run..died with no error  
message.  The second at format_process_maps seemed to work better in  
that the script when running by it self didn't hang.  But when I ran  
another configure script in a different window it did hang pretty  
quickly.  I'm going to look into this more.

>
>   That all fits right in with your diagnosis of the problem; a  
> deadlock of
> some kind I guess is the only thing that could make  
> GetModuleFileName hang.
>
>   Have you got a stack backtrace showing the call chain when this  
> problem
> arises?
>
Here is all of the bt's for all of the threads in the program.  If  
you need more information let me know.  But I probably won't be able  
to get it until next week.  My company is moving and things have to  
be turned off for a bit.

Administrator@cygwin-11 ~/tmp/debug/build/i686-pc-cygwin/winsup/cygwin
$ gdb /usr/bin/sh.exe -x try.cmd
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "i686-pc-cygwin"...
add symbol table from file "cygwin1.dbg" at
warning: no loadable sections found in added symbol-file /home/ 
Administrator/tmp
/debug/build/i686-pc-cygwin/winsup/cygwin/cygwin1.dbg
Breakpoint 1 at 0x610164f7: file ../../../../cygwin- 
snapshot-20060222-1/winsup/cygwin/exceptions.cc, line 312.
(gdb) attach 1056
Attaching to program `/usr/bin/sh.exe', process 1056
[Switching to thread 1056.0x3ac]
(gdb) info threads
* 5 thread 1056.0x3ac  0x77fa144c in ntdll!DbgUiConnectToDbg ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
   4 thread 1056.0x53c  0x77f94091 in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
   3 thread 1056.0x538  0x77f94091 in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
   2 thread 1056.0x4fc  0x77f95aae in ntdll!ZwQueryVirtualMemory ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
   1 thread 1056.0x3ec  0x610011ad in gotit ()
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203
Current language:  auto; currently c++
(gdb) thread 1
[Switching to thread 1 (thread 1056.0x3ec)]#0  0x610011ad in gotit ()
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203
203     std_dll_init ()
(gdb) bt
#0  0x610011ad in gotit ()
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203
#1  0x6107b540 in fill_rusage (r=0x22e6e0, h=0x3c4)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
resource.cc:79
#2  0x6106e923 in pinfo::exit (this=0x22e648, n=0)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/pinfo.cc: 
156
#3  0x610048e7 in do_exit (status=0)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1118
#4  0x61004cf2 in _exit (n=0)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1146
#5  0x610dcccc in exit (code=0)
     at ../../../../../cygwin-snapshot-20060222-1/newlib/libc/stdlib/ 
exit.c:65
#6  0x61004cc1 in cygwin_exit (n=0)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1140
#7  0x004104d8 in execute_command_internal (command=0x555f08,  
asynchronous=0,
     pipe_in=-1, pipe_out=-1, fds_to_close=0x556240)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:3693
#8  0x00412530 in execute_command (command=0x555f08)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:347
#9  0x00410345 in execute_command_internal (command=0x556080,  
asynchronous=0,
     pipe_in=-1, pipe_out=-1, fds_to_close=0x556280)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:2370
#10 0x00412530 in execute_command (command=0x556080)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:347
---Type <return> to continue, or q <return> to quit---
#11 0x00412771 in execute_for_command (for_command=0x556098)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:1660
#12 0x004102e5 in execute_command_internal (command=0x5560b0,  
asynchronous=0,
     pipe_in=-1, pipe_out=-1, fds_to_close=0x5560c8)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:731
#13 0x00412530 in execute_command (command=0x5560b0)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:347
#14 0x00403999 in reader_loop ()
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/eval.c:146
#15 0x00402a8f in main (argc=26, argv=0x6116124c, env=0x550090)
     at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/shell.c:704
(gdb) thread 2
[Switching to thread 2 (thread 1056.0x4fc)]#0  0x77f95aae in ntdll! 
ZwQueryVirtualMemory () from /cygdrive/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f95aae in ntdll!ZwQueryVirtualMemory ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
#1  0x7c4fa17e in VirtualQueryEx ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#2  0x7c4fa15f in VirtualQuery () from /cygdrive/c/WINNT/system32/ 
KERNEL32.DLL
#3  0x61016406 in inside_kernel (cx=0x18b9e680)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
exceptions.cc:298
#4  0x18b9e5e0 in ?? ()
#5  0x0000001c in ?? ()
#6  0x77f92b8a in ntdll!LdrQueryProcessModuleInformation ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
#7  0x7c4e0000 in ?? ()
#8  0x18b9e600 in ?? ()
#9  0x00000000 in ?? () from
(gdb) thread 3
[Switching to thread 3 (thread 1056.0x538)]#0  0x77f94091 in ntdll! 
ZwWaitForSingleObject () from /cygdrive/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f94091 in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
#1  0x7c4fc4c2 in WaitForSingleObjectEx ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#2  0x7c4f1b1b in WaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#3  0x000002e8 in ?? ()
#4  0xffffffff in ?? ()
#5  0x00000000 in ?? () from
(gdb) thread 4
[Switching to thread 4 (thread 1056.0x53c)]#0  0x77f94091 in ntdll! 
ZwWaitForSingleObject () from /cygdrive/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f94091 in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
#1  0x7c4fc4c2 in WaitForSingleObjectEx ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#2  0x7c4f1b1b in WaitForSingleObject ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#3  0x00000310 in ?? ()
#4  0xffffffff in ?? ()
#5  0x00000000 in ?? () from
(gdb) thread 5
[Switching to thread 5 (thread 1056.0x3ac)]#0  0x77fa144c in ntdll! 
DbgUiConnectToDbg () from /cygdrive/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77fa144c in ntdll!DbgUiConnectToDbg ()
    from /cygdrive/c/WINNT/system32/NTDLL.DLL
#1  0x7c50dfdb in KERNEL32!DebugActiveProcess ()
    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
#2  0x61004419 in _cygtls::call2 (func=0, arg=0x0, buf=0x0)
     at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
cygtls.cc:74
#3  0x00000000 in ?? () from
(gdb)

I used this command file to set things up.
dll-symbols cygwin1.dbg
add-symbol-file cygwin1.dbg

b exceptions.cc:312


>   We may be able to come up with a substitute for GMFN that would  
> solve the
> problem.
>
I'm now not 100% is a problem exclusive to GMFN.  I did some more  
digging and it seems like any function that can acquire the "loader  
lock" can potentially deadlock. Here is an article that discusses the  
loader lock a little bit.
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

Peter

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

More information about the Cygwin mailing list