Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 9 Sep 2001 20:20:54 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: fixup_after_fork_not?
Message-ID: <20010909202054.A12281@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <1000080113 DOT 13897 DOT 9 DOT camel AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1000080113.13897.9.camel@lifelesswks>
User-Agent: Mutt/1.3.21i

On Mon, Sep 10, 2001 at 10:01:52AM +1000, Robert Collins wrote:
>In my win95 pthread work, I'm attempting to add a new fixup_after_fork()
>routine, to be called from fork.cc after the fixup_signal_after_fork.
>The function I'm creating generates new mutex objects...
>
>However I have a problem, some insight would be appreciated :]
>
>1) I can't run a non-stripped cygwin1.dll - not enough memory to load
>cygwin1.dll. Don't know why, will try on win2k tonight. My changes don't
>cause this btw.
>2) either a) System_printfs consistently don't get written to the
>console by the forked process, or b) fork() doesn't trigger the fixup
>routine?! 
>
>By this I mean I've added a few system printf's as a substitute for a
>non-stripped .dll...
>
>in tcsh, calling ps will result in the printfs coming on screen - the
>routine is firing.
>in bash, calling ps will not result in the printfs showing. Now IIRC
>tcsh uses exec, bash uses fork? 
>
>anyway, the test program uses plain old fork(), and _never_ shows the
>system printfs. It also crashes as I would expect if the fixup routine
>isn't firing.
>
>Is there anything in the current .dll that would prevent the fixup_ set
>of routines being reached in the child by a plain old fork() call on
>win95?

I'm having no problems running a debugging version of cygwin.  I just did
it to track down the heap problem.

I set CYGWIN_SLEEP=5000 and attached, via gdb, to the displayed pid to
see why it was having problems.  You have to 'configure --enable-debug'
for this feature to be active, though.

I'm pretty sure that the fork fixup routines are running.  If they weren't
then fork wouldn't be operational.

I added a malloc mutex lock in the parent call to prevent heap instability
during fork.  I don't see how that could cause this, though.

You do have to make sure that you call anything which uses malloc at the
proper point or some things (like mutos) won't be properly initialized.
Putting your routine after signal_fixup may be too early.  Try putting
it before the sigproc_init.

I've just reduced the size of the problematic 'zombies' array.  I don't know
if that is what is causing your size problems but it should make the DLL
noticeably smaller.

If you can't, for some reason, debug a DLL that is entirely built with -g,
try compiling everything except fork.cc and thread.c (or whatever) with '-O2'
and those to files with '-g'.

You are using the latest version of binutils, right?

cgf