Ludovic Courtès wrote:
Boris Zbarsky <[EMAIL PROTECTED]> writes:
That doesn't seem to have any effect. Interestingly, if I change the
setitimer call but NOT the sigaction call I see the program terminate
with an uncaught SIGPROF... So clearly the sigaction is having _some_
effect. Just not th
Hello,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> That doesn't seem to have any effect. Interestingly, if I change the
> setitimer call but NOT the sigaction call I see the program terminate
> with an uncaught SIGPROF... So clearly the sigaction is having _some_
> effect. Just not that of cal
Ludovic Courtès wrote:
Maybe with `strace(1)' or similar?
Unfortunately, that just shows the pointer to the struct, not the
value in the struct itself
Under GNU/Linux it does the right thing. :-)
Ah, cool. I'll dig up my Linux machine at some point to double-check
this if I exhaust al
Hi,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> Ludovic Courtès wrote:
>> Maybe with `strace(1)' or similar?
>
> Unfortunately, that just shows the pointer to the struct, not the
> value in the struct itself
Under GNU/Linux it does the right thing. :-)
> I tried adding that call to code t
Ludovic Courtès wrote:
I can't check the values in the structs it's passed, unfortunately (no
symbols here for guile or the libc).
Maybe with `strace(1)' or similar?
Unfortunately, that just shows the pointer to the struct, not the value
in the struct itself
Another (remote) possibili
Hello,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> Sure. The wrong thing is that profile-signal-handler is not called,
> so never resets the timer, so no more SIGPROFs. Unless I'm misreading
> the code.
Oh, right.
> I can't check the values in the structs it's passed, unfortunately (no
> symb
Ludovic Courtès wrote:
GDB supposedly shows all SIGPROFs that are raised, so if it shows only
one, then something's wrong.
Sure. The wrong thing is that profile-signal-handler is not called, so
never resets the timer, so no more SIGPROFs. Unless I'm misreading the
code.
Can you check the
Hi,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> 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
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/
T
Hello,
Boris Zbarsky <[EMAIL PROTECTED]> writes:
> I'm having a bit of a problem with using statprof. I checked it out
> from CVS (:pserver:[EMAIL PROTECTED]:/sources/guile
> CVSROOT, guile/guile-statprof module). I left it in the checkout
> tree, and am using GUILE_LOAD_PATH to point to the fi
10 matches
Mail list logo
