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] |
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] |