X-Spam-Check-By: sourceware.org Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <000301c638a4$dfc6fd70$a501a8c0@CAM.ARTIMI.COM> References: <000301c638a4$dfc6fd70$a501a8c0 AT CAM DOT ARTIMI DOT COM> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10C8EE35-B5B3-40CD-B9EA-122E2CB26343@rehley.net> Content-Transfer-Encoding: 7bit From: Peter Rehley Subject: Re: Hanging at GetModuleFileName in inside_kernel function Date: Thu, 23 Feb 2006 15:43:25 -0800 To: Cygwin List X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: 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 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 AT 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 to continue, or q 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/