This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: mtrace && fork
- To: aj at suse dot de
- Subject: Re: mtrace && fork
- From: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Date: Mon, 18 Sep 2000 16:26:50 +0200 (MDT)
- CC: libc-alpha at sourceware dot cygnus dot com, bastian at suse dot de
- References: <u8u2bdergn.fsf@gromit.rhein-neckar.de>
[Sorry, please discard the previous truncated mail..]
> Waldo reported the following problem together with a patch for mtrace:
> > With some further investigation I found the problem, ksysguard use KProcess
> > to fork and start a child process. This confuses the hell out of [k/m]trace
> > because there are now suddenly two process that write to the same logfile.
>
> What do you think of the patch? Is it ok to apply? Or how shall we
> handle the situation?
Overriding fork() is certainly one possible solution, however it has
little to no chance to work with threads.
I'm sorry, I still haven't looked at mtrace in glibc in detail.
However, I suspect output to the trace file stream is buffered (if
not, maybe it should be..). One could record the pid at mtrace
startup. Every time the buffer is full and needs to be written out to
the trace file, getpid() is checked against the saved value and if it
doesn't match, the stream is closed.
At least this is the way I got around the problem in
ftp://ftp.dent.med.uni-muenchen.de/pub/wmglo/mtrace-970904.tar.gz
(long overdue for an update!)
Regards,
Wolfram.