child process initialization as part of fork() -- STC

[Mark Geisert]

Sorry for the noise.  I had assumed something and posted about it before 
checking more thoroughly...

Corinna Vinschen wrote:
> Hi Mark,
>
> On Mar  8 00:20, Mark Geisert wrote:
>> -------- compile, link, and run
>> ~ gcc -nostdlib -pg -g -o stc stc.c build/gcrt0.o build/crt0.o
>> build/libgmon.a build/libcygwin.a /c/Windows/system32/kernel32.dll -lgcc
>>
>> ~ strace -o stc.out --mask=debug+sigp+syscall ./stc
 >> 5592: _monstartup called
>> 5592: monstartup called
>> 5592: moncontrol called
>> 5592: profile_off called
>> 5592: profile_on called
>> 5592: _monstartup called  <-- this is the odd message I'm asking about
>> 5592: I'm a constructor
>> 5592: I'm the parent

...parent 5592 does the fork() here...

>> 5504: I'm the child
>> 5504: I'm a destructor
>> 5504: _mcleanup called
>> 5504: moncontrol called
>> 5504: profile_off called
>> 5592: I'm a destructor
>> 5592: _mcleanup called
>> 5592: moncontrol called
>> 5592: profile_off called
>>
>> ~
>>
>> In the above compilation command, "build" is a symlink to
>> /oss/build/x86_64-unknown-cygwin/winsup/cygwin/
>>
>> I've patched several routines in Cygwin DLL and libgmon.a to call my note()
>> function just to announce they've been reached and to say what pid they're
>> running in.  It looks like libgmon's _monstartup() is called twice, which is
>> expected, but both times in the parent's process, which is not expected.
>
> I'm not set up to test this locally.  Can you please check the *Windows*
> PID as well in your note function?  There's a chance this is a false
> positive.  Dependent on when the constructors are called, the Cygwin
> PID might not be set yet in the child.

I checked Windows pids as well as Cygwin pids and they are 1:1 throughout the 
STC.  But I've now noticed the 2nd call to _monstartup is being done before 
main() is entered in the parent.  So it has nothing to do with fork() setting up 
the child.

And now that I think about it, fork() copies the "constructed" address space 
from parent to child so there should be no need to run constructors again.  I 
need another mechanism to update libgmon static data and start up a profiling 
thread in the child after a fork().  Maybe pthread_atfork() is the way.

..mark