This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Is gprof profiling (-pg) reentrant/thread-safe?
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Stu Juengst <juengst at rubiconlabs dot io>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Tue, 3 May 2016 11:22:54 -0400
- Subject: Re: Is gprof profiling (-pg) reentrant/thread-safe?
- Authentication-results: sourceware.org; auth=none
- References: <30CA35B9-6EC3-4E34-AF8F-38632BC1D56D at rubiconlabs dot io>
On Tue, May 3, 2016 at 10:36 AM, Stu Juengst <juengst@rubiconlabs.io> wrote:
> I was seeing some mysterious segmentation faults in my multi-threaded Linux application which was built with the -pg option for gprof profiling. They went away when I turned -pg off. I took a look at the mcount source for the version of glibc that I'm using (2.2.5) and see that it is updating linked lists in a single global structure (_gmonparam) with no synchronization mechanism to keep multiple threads from accessing this structure simultaneously. Am I missing something, or is gprof profiling not reentrant/thread-safe?
The profil() function in glibc is not thread safe, and it says this in
the manual.
It *should* be thread safe, but nobody has done the work to enhance it.
Please note that thread-safety and reetrancy are two distinct things.
Cheers,
Carlos.