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
