This is the mail archive of the cygwin-developers 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]
Other format: [Raw text]

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


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


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