Re: Issues using statprof (no samples taken)

[Boris Zbarsky]

Ludovic Courtès wrote:
> Beware, Guile's CVS repository is no longer used, so software in there
> is essentially unmaintained.
>
> As far as `statprof' is concerned, I would recommend using the one
> available in Guile-Lib, since it's been maintained there for some time:
> http://home.gna.org/guile-lib/

Thanks for that pointer!  I'd seen documentation for this version of 
statprof at http://wingolog.org/software/guile-lib/statprof/ but that 
didn't have any links to the guile-lib download.  It might be worth 
updating 
http://www.gnu.org/software/guile/docs/faq/guile-faq.html#Is-there-a-Scheme-code-profiler-that-works-with-Guile_003f 
with the new location, maybe.

Unfortunately, this version still has the issue I ran into.

> > I am using guile 1.6.8 on Mac OS X, installed via Macports.
>
> Is there any particular reason why you don't use 1.8.x?

Yes.  As my original mail said, 1.6.8 is what gnucash is compiled 
against and uses in this case, and I'm trying .  I don't see an obvious 
way to change that without trying to recompile gnucash with some sort of 
modifications, which I'd rather avoid having to mess with if I can.

> Can you check whether SIGPROF is actually delivered and whether
> `profile-signal-handler' gets called, e.g., by adding a `(display
> "foo\n")' call there?

profile-signal-handler is not getting called.  I do see a SIGPROF 
delivered to the gnucash-bin process (using 'handle SIGPROF stop' in gdb 
after attaching to the gnucash-bin process), but only once during the 
entire report generation.  I also see scm_setitimer called in gdb at a 
point in the scheme code that matches the call to (statprof-start), and 
I see it called again at the point that matches (statprof-stop).  The 
single SIGPROF delivered comes soon after that first setitimer call.

So sounds like something is capturing the SIGPROF, I guess, so we never 
get that first sample and never reset the profiling timer.

I don't see any obvious sigaction() or signal() calls in the gnucash 
source tree, unfortunately.  Maybe they're hidden away in some sort of 
API calls gnucash makes...  Is there any way to tell in gdb which signal 
handler is actually getting called for the signal?  Or something else I 
should grep for in the gnucash source?

Thank you again,
Boris