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

[Chris Faylor <cgf at cygnus dot com>]

On Thu, Jul 06, 2000 at 09:49:33AM +1000, Robert Collins wrote:
>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.

Are you using gdb -nw?  And, I assume you've built a DLL with -g.

There are multiple lines of source below.  I guess that this does isolate
things in terms of all of the Cygwin DLL but why didn't you report the
specific line where it is dying???

I have no idea why your source is not being printed.  I do this every
day.  Possibly you need to use the directory command to add a source
directory for searching.

>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

That would normally be the sign of two different cygwin's being executed.
Otherwise, is it possible that this the code is being forked from a thread()?

cgf

>===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
>>

-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourceware.cygnus.com/         http://www.redhat.com/