Re: Issues using statprof (no samples taken)

[Boris Zbarsky <bzbarsky@MIT.EDU>]

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 all other possibilities.

>> I tried adding that call to code that certainly runs repeatedly
>> between statprof-start and statprof-stop (the code that handles
>> updating the gnucash progress bar, in fact), but that doesn't seem to
>> help.
> 
> Are you sure that piece of code is ever called?

Absolutely.  Adding display statements there prints stuff.

> Is it called from an "idle" handler or some such?

Not that I can tell.  More precisely, the code now looks more or less 
like this:

(statprof-reset 0 500 #t)
(statprof-start)
(set! foo (map (lambda (bar) (body)) myList))
(statprof-stop)
(statprof-display)

where (body) includes the (select) calls you suggested.

> Another idea is that you could try modifying `statprof' so that it uses
> 
>   (setitimer ITIMER_REAL ...)
> 
> and
> 
>   (sigaction SIGALRM profile-signal-handler)
> 
> just to see if it makes a difference...

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 calling the handler.  ;)

> It may be that they use a single pthread (the "main" thread), and that
> they handle events and timeouts via a GTK+ even loop.

Quite possible, yes.

> Can you check with GDB whether `pthread_create(3)' is ever called?

Yes, it is, with this stack:

(gdb) where
#0  0x91df0f80 in pthread_create ()
#1  0x016c5ac3 in g_thread_create_posix_impl ()
#2  0x01772f93 in g_thread_create_full ()
#3  0x0174686a in g_child_watch_source_init_multi_threaded ()
#4  0x01746a15 in g_child_watch_source_new ()
#5  0x01746a57 in g_child_watch_add_full ()
#6  0x01746b1f in g_child_watch_add ()
#7  0x003459f3 in gnc_spawn_process_async ()
#8  0x0033412b in _wrap_gnc_spawn_process_async ()
#9  0x0161a312 in scm_deval ()
#10 0x01616364 in scm_deval ()
#11 0x0161bc27 in scm_dapply ()
#12 0x01611ee7 in scm_apply ()
#13 0x01611c20 in scm_call_0 ()
#14 0x01602b2c in scm_dynamic_wind ()
#15 0x0161aa96 in scm_deval ()
#16 0x01615f6a in scm_deval ()
#17 0x01613727 in scm_i_eval_x ()
#18 0x016137fb in scm_primitive_eval_x ()
#19 0x01665cd6 in inner_eval_string ()
#20 0x0161de4d in scm_c_with_fluids ()
#21 0x0161dec6 in scm_c_with_fluid ()
#22 0x01637baf in scm_c_call_with_current_module ()
#23 0x01665d4a in scm_eval_string ()
#24 0x01665c5c in scm_c_eval_string ()
#25 0x00003961 in inner_main ()
#26 0x016331f9 in invoke_main_func ()
#27 0x016331a4 in scm_boot_guile_1 ()
#28 0x01632eb1 in scm_boot_guile ()
#29 0x000042a2 in main ()

That seems to be the only pthread_create call.  Looking through the 
gnucash source, the gnc-spawn-process-async call seems to be spinning up 
a separate process (well, thread in this case) to handle getting price 
quotes over the network...

-Boris