Re: cygwin1.dll (v1.1.2): dup2() with invalid newfd lead to exception: STATUS_ACCESS_VIOLATION

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

I've moved this from the main list to this list as it is an application
topic.

Chris, thanks for the tips w/debugging this, I''ve had limited success.

I think I have isolated the code where the stackdump occurs (see below) but
when I attempt to attach to the process (I used longer sleep calls than
shown) gdb won't show the source, or even the assembly.

AFAICT I had to have gdb open and use the attach command? because otherwise
it also got caught by the sleep call...

Any suggestions as to the next stop? I did this from the snapshot 6/28, but
it was occuring under 1.1.1 & 1.1.2

thanks in advance,
Rob

===dcrt0.cc function dll_crt0_1===
small_printf ("1my pid %d\n", GetCurrentProcessId ());
Sleep(900);
if (user_data->forkee)
{
/* If we've played with the stack, stacksize != 0. That means that
fork() was invoked from other than the main thread. Make sure that
frame pointer is referencing the new stack so that the OS knows what
to do when it needs to increase the size of the stack.
NOTE: Don't do anything that involves the stack until you've completed
this step. */
if (ciresrv->stacksize)
{
asm ("movl %0,%%fs:4" : : "r" (ciresrv->stackbottom));
asm ("movl %0,%%fs:8" : : "r" (ciresrv->stacktop));
}
longjmp (ciresrv->jmp, ciresrv->cygpid);
}
small_printf ("2my pid %d\n", GetCurrentProcessId ());
Sleep(100);
===
with the stackdump as follows
Exception: STATUS_ACCESS_VIOLATION at eip=61028AA1
eax=026BFDE8 ebx=00000000 ecx=00000000 edx=61081C28 esi=00000000
edi=FFFFFFFF
ebp=026BFDAC esp=026BFC64 program=E:\cygwin\usr\local\squid\bin\squid.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
026BFDAC  6101E22A  (00000000, 026BFDE8, 00000000, 61070EF8)
026BFE3C  6101E22A  (61081C28, 00000000, 00000000, 00000000)
026BFE6C  6101E522  (61081C28, 00000000, 00000000, 00000000)
026BFEBC  6101F0D2  (61081C28, 00020938, 026BFEFC, 6102DDE8)
026BFEFC  6102DE02  (00020938, 7FFDF000, 0002091C, 026BFF60)
026BFF30  610021F6  (00000000, 00000000, 026BFF70, 00492D26)
026BFF60  61002735  (0050C990, 00000000, 026BFF90, 00492D76)
026BFF90  00492D83  (00450234, FFFFFFFF, 80430B27, 00000000)
026BFFC0  0040103B  (00000000, 00000000, 7FFDF000, 00000000)
026BFFF0  77E87903  (00401000, 00000000, 000000C8, 00000100)
End of stack tracebash-2.04$

----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
To: <cygwin@sourceware.cygnus.com>
Sent: Tuesday, June 27, 2000 8:57 AM
Subject: Re: cygwin1.dll (v1.1.2): dup2() with invalid newfd lead to
exception: STATUS_ACCESS_VIOLATION


> On Tue, Jun 27, 2000 at 08:39:56AM +1000, Robert Collins wrote:
> >    any time to look at a bug report on a fork() call? Its the same
package
> >(squid 2.3-STABLE3) during startup, it stackdumps. I have been trying to
> >debug this w/gdb (both your updated version, and the text-console version
5
> >from sourceware). gdb seems to work ok, but I cannot follow the second
> >thread..
> >I have included a stackdump and the funciton that calls fork().
>
> You'll notice that this is very different from the original problem.
>
> I was able to debug the original problem because the user provided a
> code snippet that demonstrated the problem.  Providing code that shows a
> fork() call does not really demonstrate anything.
>
> You don't seem to have tried to figure out where, specifically, the
> code is dying.  It seems to be in the cygwin DLL (which doesn't mean
> that it is cygwin) but I don't know where.
>
> If you have a cygwin1.dll with debugging symbols, you can get the symbolic
> addresses by using the "list" command, i.e.
>
> list *6101EC4E
>
> I'm not sure what thread you are referring to.  If it is the other process
> then gdb has no way to debug another process currently, unfortunately.
>
> One technique that I use to work around this is to build a cygwin1.dll
> and put something like a:
>
> small_printf ("my pid %d\n", GetCurrentProcessId ());
> Sleep(15000);
>
> somewhere in the dll_crt0_1 startup code.  When the pid is printed, I then
> attach to that pid using gdb:
>
> gdb theprogram.exe nnnn
>
> Where nnnn is the reported pid.
>
> cgf
>