[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues using statprof (no samples taken)

From: Boris Zbarsky
Subject: Re: Issues using statprof (no samples taken)
Date: Tue, 18 Nov 2008 11:15:50 -0500
User-agent: Thunderbird (Macintosh/20080914)

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

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)
(set! foo (map (lambda (bar) (body)) myList))

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

Another idea is that you could try modifying `statprof' so that it uses

  (setitimer ITIMER_REAL ...)


  (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...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]