Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Subject: fixup_after_fork_not? From: Robert Collins To: cygwin-developers AT cygwin DOT com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13 (Preview Release) Date: 10 Sep 2001 10:01:52 +1000 Message-Id: <1000080113.13897.9.camel@lifelesswks> Mime-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2001 23:48:44.0158 (UTC) FILETIME=[F5E171E0:01C13989] 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? Rob