This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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@cygnus.com]
Sent: Tuesday, 27 June 2000 8:58 AM
To: cygwin@sourceware.cygnus.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@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]