Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: RE: cygwin1.dll (v1.1.2): dup2() with invalid newfd lead to exception: STATUS_ACCESS_VIOLATION
Date: Tue, 27 Jun 2000 10:09:34 +1000
Message-ID: <8600BF007197944F8DD3906E40CB4280486A@itdomain001.itdomain.net.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
content-class: urn:content-classes:message
Thread-Index: Ab/fwfBQ9ZXP9XtZT5OH8oUJ2MWIJgACKD8Q
X-MimeOLE: Produced By Microsoft Exchange V6.0.4208.0
Thread-Topic: cygwin1.dll (v1.1.2): dup2() with invalid newfd lead to exception: STATUS_ACCESS_VIOLATION
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id UAA22569

AFAICT the stackdumps occurs in fork() itself. I will try your
suggestion for getting the child process pid though.

I should have used process not thread before (oops), but nonetheless I
thought gdb had an option when fork() is called to follow the parent or
child process? I tried setting that when debugging but got nowhere.

Thanks for the help,
Rob

-----Original Message-----
From: Chris Faylor [mailto:cgf AT cygnus DOT com]
Sent: Tuesday, 27 June 2000 8:58 AM
To: cygwin AT sourceware DOT cygnus DOT com
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


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com