X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Message-ID: <4AD7B135.6020401@cwilson.fastmail.fm> Date: Thu, 15 Oct 2009 19:33:09 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: fork failure? References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> <4AD73B83 DOT 9060505 AT gmail DOT com> <4AD74586 DOT 8070803 AT cwilson DOT fastmail DOT fm> <4AD752C8 DOT 2040908 AT gmail DOT com> In-Reply-To: <4AD752C8.2040908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Dave Korn wrote: > Charles Wilson wrote: >> I'm not familiar at all with procmon (sysinternals, right?) but I'll >> look into it. > > Yep, it's dead useful for making sure that stuff at least starts up, and you > can often get a clue how far the code has got by seeing what handles it's > opened and syscalls its made. Well, it appears that the child is dying in dcrt0.c dll_crt0_1() when it calls cygheap->cwd.init(). The line numbers below are a little messed up (I need to build with -O0 to get more info), but here are the last four interesting events from the child...with the top few frames of the stack trace for each, manually converted using addr2line... 43673 6:58:17.3634216 PM gpg-agent.exe 568 CreateFile C:\cygwin-1.7 SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 7628 "12","ntdll.dll","ntdll.dll + 0x587f4", "0x771387f4", "13","cygwin1.dll","cygwin1.dll + 0x89fe8","0x61089fe8" path.cc:3225 cwdstuff::set(_UNICODE_STRING*, char const*, bool) "14","cygwin1.dll","cygwin1.dll + 0x8a4d8","0x6108a4d8", path.cc:3168 cwdstuff::init() "15","cygwin1.dll","cygwin1.dll + 0x6722","0x61006722", dcrt0.c:798 dll_crt0_1() 43674 6:58:17.3634756 PM gpg-agent.exe 568 CloseFile C:\cygwin-1.7 SUCCESS 7628 "11","ntdll.dll","ntdll.dll + 0x57f54","0x77137f54", "12","cygwin1.dll","cygwin1.dll + 0x8a003","0x6108a003", path.cc:3241 cwdstuff::set(_UNICODE_STRING*, char const*, bool) "13","cygwin1.dll","cygwin1.dll + 0x8a4d8","0x6108a4d8", path.cc:3168 cwdstuff::init() "14","cygwin1.dll","cygwin1.dll + 0x6722","0x61006722", dcrt0.c:798 dll_crt0_1() NOTE: next entry is from thread 2228, not 7628 53626 6:58:19.0002272 PM gpg-agent.exe 568 Thread Exit SUCCESS User Time: 0.0000000, Kernel Time: 0.0000000 2228 "5","kernel32.dll","kernel32.dll + 0x4046b","0x7704046b", "6","cygwin1.dll","cygwin1.dll + 0xbabf5","0x610babf5", sigproc.cc:1191 wait_sig(void*) "7","cygwin1.dll","cygwin1.dll + 0x3fec","0x61003fec", cygthread.cc:50 cygthread::callfunc(bool) 53627 6:58:19.0005306 PM gpg-agent.exe 568 Thread Exit SUCCESS User Time: 0.0000000, Kernel Time: 0.0156001 7628 "7","ntkrnlpa.exe","ntkrnlpa.exe + 0x57a1a","0x820a3a1a" "8","ntdll.dll","ntdll.dll + 0x80e35","0x77160e35", So it looks to me like something in cwdstuff::init() triggered a signal, which was caught by cygwin and handled by aborting. Does that analysis look right? If so, then I guess I need to rebuild the DLL with --enable-debugging and -O0, so I can find out exactly WHY that's happening. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple