X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AD8D490.2040000@gmail.com> Date: Fri, 16 Oct 2009 21:16:16 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) 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> <4AD7B135 DOT 6020401 AT cwilson DOT fastmail DOT fm> <4AD8220D DOT 8000908 AT cwilson DOT fastmail DOT fm> <4AD8AD47 DOT 6010605 AT cwilson DOT fastmail DOT fm> <4AD8B90B DOT 4040507 AT gmail DOT com> <4AD8CD8A DOT 7010708 AT cwilson DOT fastmail DOT fm> In-Reply-To: <4AD8CD8A.7010708@cwilson.fastmail.fm> 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 Charles Wilson wrote: > ModLoad: 75bd0000 75c7a000 C:\Windows\system32\msvcrt.dll Say, what's that doing there? Might like to check who's pulling it in, just in case something's gone all win32 on you that shouldn't be. > ModLoad: 6c1b0000 6c1b5000 C:\Windows\system32\avgrsstx.dll Let's hope AVG hasn't gone (even further) over to the dark side. > (f78.1938): Break instruction exception - code 80000003 (first chance) > eax=7ffdc000 ebx=00000000 ecx=00000000 edx=7716d094 esi=00000000 > edi=00000000 > eip=77127dfe esp=1a49ff5c ebp=1a49ff88 iopl=0 nv up ei pl zr na > pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000246 > ntdll!DbgBreakPoint: > 77127dfe cc int 3 > 0:002> g > (f78.1118): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000000 ebx=0136cab8 ecx=00000000 edx=ffffffff esi=00000007 > edi=00404119 > eip=00000000 esp=7ff8f6fc ebp=7ff8f984 iopl=0 nv up ei pl zr na > pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010246 > 00000000 ?? ??? > 0:000> k > ChildEBP RetAddr > WARNING: Frame IP not in any known module. Following frames may be wrong. > 7ff8f984 00000000 0x0 > > > which is just after the output window gets: > returning from fork: ischild=1, res=0 > > So, this is the right spot. And $eip is 0x0. That doesn't tell me much... So, the dreaded jump-to-zero. Always a tricky one, since by the time you get there you have no idea where you came there from. Except that we suspect fork(). I'd set a breakpoint on the start of fork and another one on the ret at the end of it, (did you try mingw gdb yet? it might be easier here than windbg since it'll understand the symbols, but if you can't get it to work then you can manually look up symbol addresses and set the breakpoints by hex address), and then I'd restart the program, note the value of $esp and verify a sane-looking return address on entry to the function, let it run to the end of the function and find out if the stack pointer wasn't back at the same location or if the return address there had been corrupted. The second of those could potentially be tracked down using a hardware breakpoint (watchpoint in gdb terminology), the first of those two would require reading the code to see why it's not popping and pushing in equal amounts. cheers, DaveK -- 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