I have the following situation: A linux binary is searching a specific directory for shared libraries. All found shared libraries are later used as a plugin. Now the binary sets signal handlers for everything and exits when it gets *any* signal. The binary can not be used with -fPIC-compiled plugins. As I don't have the code for the binary but need to (cpu and heap) profile one of the plugins my only option is LD_PRELOAD. During initialisation of the cpu profiler a SIGPROF-signal is sent and the binary exits.
So, what I want to do:
1. ProfileHandler already has an option to disallow profiling, which is set to "allow" by default. I set this to disallow and added a new function to allow profiling from the outside (the plugin). 2. This new function will toggle the allow-flag and call Init(). 3. Then in the plugin I call RegisterThread() and ProfilerStart()/ProfilerStop() for my only thread I want to profile.
Now I get a crash somewhere which I can't catch in a debugger.
Have I initialised everything correctly? Is there a better way to do this?
Interesting problem Enrico. From the perspective of the profiler it looks
like you have the right initialization. What kind of crash is being
generated? abort? segfault? can you share the backtrace?
-Dave
On Thu, Nov 15, 2012 at 9:16 PM, Enrico Zschemisch <ezsch...@gmail.com>wrote:
> I have the following situation: A linux binary is searching a specific
> directory for shared libraries. All found shared libraries are later used
> as a plugin. Now the binary sets signal handlers for everything and exits
> when it gets *any* signal. The binary can not be used with -fPIC-compiled
> plugins.
> As I don't have the code for the binary but need to (cpu and heap) profile
> one of the plugins my only option is LD_PRELOAD.
> During initialisation of the cpu profiler a SIGPROF-signal is sent and the
> binary exits.
> So, what I want to do:
> 1. ProfileHandler already has an option to disallow profiling, which
> is set to "allow" by default. I set this to disallow and added a new
> function to allow profiling from the outside (the plugin).
> 2. This new function will toggle the allow-flag and call Init().
> 3. Then in the plugin I call RegisterThread() and
> ProfilerStart()/ProfilerStop() for my only thread I want to profile.
> Now I get a crash somewhere which I can't catch in a debugger.
> Have I initialised everything correctly? Is there a better way to do this?
> Thanks,
> Enrico
> --
> You received this message because you are subscribed to the Google Groups
> "google-perftools" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-perftools/-/GJCHMtPJzFoJ.
> To post to this group, send email to google-perftools@googlegroups.com.
> To unsubscribe from this group, send email to
> google-perftools+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-perftools?hl=en.
I looked into this again today: The binary reports it is "crashed", however gdb prints: *Program terminated with signal SIGPROF, Profiling timer expired.* * * My search gave that this happens when the signal is sent before a handler is registered. So I changed the sequence to:
1. disallow profiling in ProfileHandler 2. Binary & Plugin startup 3. Call new ProfilerInit() to call InitAllowed() on the ProfileHandler: Will create a new instance with allowed = true 4. Call ProfilerStart() which calls EnableHandler() to register a signal handler 5. Call ProfilerRegisterThread() in my plugin's only (main) thread.
The binary will still exit with the above error message about an expired timer. I made sure there is no *setitimer() *or *alarm()*-call before * EnableHandler()*. The signal is coming from *StartTimer()*, which is called from* ProfilerRegisterThread()*.
One more thing: I had to bypass the check in for an existing SIG_PROF-handler in ProfileHandler's ctor, as the binary already has one installed (which it uses to exit then).
Any idea or suggestion on how to get this working?
> I looked into this again today: The binary reports it is "crashed",
> however gdb prints:
> *Program terminated with signal SIGPROF, Profiling timer expired.*
> *
> *
> My search gave that this happens when the signal is sent before a handler
> is registered. So I changed the sequence to:
> 1. disallow profiling in ProfileHandler
> 2. Binary & Plugin startup
> 3. Call new ProfilerInit() to call InitAllowed() on the
> ProfileHandler: Will create a new instance with allowed = true
> 4. Call ProfilerStart() which calls EnableHandler() to register a
> signal handler
> 5. Call ProfilerRegisterThread() in my plugin's only (main) thread.
> The binary will still exit with the above error message about an expired
> timer. I made sure there is no *setitimer() *or *alarm()*-call before *
> EnableHandler()*. The signal is coming from *StartTimer()*, which is
> called from* ProfilerRegisterThread()*.
> One more thing: I had to bypass the check in for an existing
> SIG_PROF-handler in ProfileHandler's ctor, as the binary already has one
> installed (which it uses to exit then).
> Any idea or suggestion on how to get this working?
> To post to this group, send email to google-perftools@googlegroups.com.
> To unsubscribe from this group, send email to
> google-perftools+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-perftools?hl=en.
Yeah, unfortunately it has. It does not do anything with it, according to
the developers. Kind of a "catch all" on signals.
After registering gperftool's signal handler, the binary does not exit as
usual, so it seems the last signal handler registered is used. But then I
get the timeout instead.
