cpu usage in Audacity when idle

[Michael Schwendt]

Are issues like these known?

  idle audacity causes CPU to go to 85 degrees C
  https://bugzilla.redhat.com/528248
  (that is with 1.3.7-beta and Fedora 10)

  Audacity consumes lots of CPU time when idle: short timeout loop?
  https://bugzilla.redhat.com/494425
  (that is with wxGTK 2.8.10)

I dunno yet whether I'm able to reproduce it often, but with an idle 1.3.9-beta
and a loaded WAV file, cpu usage goes up quite a bit and down again without
touching it at all.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Michael Schwendt <[hidden email]>
| Sat, 10 Oct 2009 10:49:32 +0200
| Subject: [Audacity-devel] cpu usage in Audacity when idle

> Are issues like these known?
>
>   idle audacity causes CPU to go to 85 degrees C
>   https://bugzilla.redhat.com/528248
>   (that is with 1.3.7-beta and Fedora 10)
>
>   Audacity consumes lots of CPU time when idle: short timeout loop?
>   https://bugzilla.redhat.com/494425
>   (that is with wxGTK 2.8.10)
>
> I dunno yet whether I'm able to reproduce it often, but with an idle 1.3.9-beta
> and a loaded WAV file, cpu usage goes up quite a bit and down again without
> touching it at all.

Yes this was brought up initially on the -users list and was discussed
recently and looked at by Al:
http://n2.nabble.com/Audacity-CVS-consumes-CPU-while-idle-Fedora-12-x86-64-tp3745332p3745332.html

I can reproduce it at will on Ubuntu 9.04, but Al couldn't. I was
going to add it as a P3 bug since it does not seem possible to
reliably reproduce it on all machines (or fix it) at the moment.

You don't even need to import a file for it to happen; just launch
Audacity.



Gale




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Benjamin Drung-2]

Am Samstag, den 10.10.2009, 18:47 +0100 schrieb Gale Andrews:

> | From Michael Schwendt <[hidden email]>
> | Sat, 10 Oct 2009 10:49:32 +0200
> | Subject: [Audacity-devel] cpu usage in Audacity when idle
> > Are issues like these known?
> >
> >   idle audacity causes CPU to go to 85 degrees C
> >   https://bugzilla.redhat.com/528248
> >   (that is with 1.3.7-beta and Fedora 10)
> >
> >   Audacity consumes lots of CPU time when idle: short timeout loop?
> >   https://bugzilla.redhat.com/494425
> >   (that is with wxGTK 2.8.10)
> >
> > I dunno yet whether I'm able to reproduce it often, but with an idle 1.3.9-beta
> > and a loaded WAV file, cpu usage goes up quite a bit and down again without
> > touching it at all.
>
> Yes this was brought up initially on the -users list and was discussed
> recently and looked at by Al:
> http://n2.nabble.com/Audacity-CVS-consumes-CPU-while-idle-Fedora-12-x86-64-tp3745332p3745332.html
>
> I can reproduce it at will on Ubuntu 9.04, but Al couldn't. I was
> going to add it as a P3 bug since it does not seem possible to
> reliably reproduce it on all machines (or fix it) at the moment.
>
> You don't even need to import a file for it to happen; just launch
> Audacity.

On one machine I get a high load, too. I use audacity 1.3.9 on Ubuntu
9.04 there. The architecture is amd64 and it's a dual display setup with
a Nvidia graphic card.

It happens while recording. The load gets back to normal if I minimize
audacity and switch to another application. So I thought that it may
have something to do with the GUI and the graphics driver.

--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Bill Wharrie]

On 10-Oct-09, at 1:47 PM, Gale Andrews wrote:

>
> | From Michael Schwendt <[hidden email]>
> | Sat, 10 Oct 2009 10:49:32 +0200
> | Subject: [Audacity-devel] cpu usage in Audacity when idle
>> Are issues like these known?
>>
>>  idle audacity causes CPU to go to 85 degrees C
>>  https://bugzilla.redhat.com/528248
>>  (that is with 1.3.7-beta and Fedora 10)
>>
>>  Audacity consumes lots of CPU time when idle: short timeout loop?
>>  https://bugzilla.redhat.com/494425
>>  (that is with wxGTK 2.8.10)
>>
>> I dunno yet whether I'm able to reproduce it often, but with an  
>> idle 1.3.9-beta
>> and a loaded WAV file, cpu usage goes up quite a bit and down again  
>> without
>> touching it at all.
>
> Yes this was brought up initially on the -users list and was discussed
> recently and looked at by Al:
> http://n2.nabble.com/Audacity-CVS-consumes-CPU-while-idle-Fedora-12-x86-64-tp3745332p3745332.html
>
> I can reproduce it at will on Ubuntu 9.04, but Al couldn't. I was
> going to add it as a P3 bug since it does not seem possible to
> reliably reproduce it on all machines (or fix it) at the moment.
>
> You don't even need to import a file for it to happen; just launch
> Audacity.
>
>
>
> Gale
>

I don't know if this is relevant, but ...

On a Mac G5 dual 2 GHz, single monitor, Audacity 1.3.9 does not  
consume excess CPU time when idle (< 2%), but, if I bring up the  
screenshot window CPU load will bounce between 10% and 100%.

- Bill

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Saturday 10 October 2009 14:27:00 Bill Wharrie wrote:

> On 10-Oct-09, at 1:47 PM, Gale Andrews wrote:
> > | From Michael Schwendt <[hidden email]>
> > | Sat, 10 Oct 2009 10:49:32 +0200
> > | Subject: [Audacity-devel] cpu usage in Audacity when idle
> >>
> >> Are issues like these known?
> >>
> >>  idle audacity causes CPU to go to 85 degrees C
> >>  https://bugzilla.redhat.com/528248
> >>  (that is with 1.3.7-beta and Fedora 10)
> >>
> >>  Audacity consumes lots of CPU time when idle: short timeout loop?
> >>  https://bugzilla.redhat.com/494425
> >>  (that is with wxGTK 2.8.10)
> >>
> >> I dunno yet whether I'm able to reproduce it often, but with an
> >> idle 1.3.9-beta
> >> and a loaded WAV file, cpu usage goes up quite a bit and down again
> >> without
> >> touching it at all.
> >
> > Yes this was brought up initially on the -users list and was discussed
> > recently and looked at by Al:
> > http://n2.nabble.com/Audacity-CVS-consumes-CPU-while-idle-Fedora-12-x86-6
> >4-tp3745332p3745332.html
> >

I may have actually seen this since upgrading Kubuntu to 9.10-beta... I
noticed my load getting unusually high when I had Audacity sitting idle while
I was doing something else.  I was more concerned with the other stuff at the
time, so I didn't pay much attention.  It went back to normal when I started
working on Audacity again.  I'll give this another test now.

> > I can reproduce it at will on Ubuntu 9.04, but Al couldn't. I was
> > going to add it as a P3 bug since it does not seem possible to
> > reliably reproduce it on all machines (or fix it) at the moment.
> >
> > You don't even need to import a file for it to happen; just launch
> > Audacity.
> >
> >
> >
> > Gale
>
> I don't know if this is relevant, but ...
>
> On a Mac G5 dual 2 GHz, single monitor, Audacity 1.3.9 does not
> consume excess CPU time when idle (< 2%), but, if I bring up the
> screenshot window CPU load will bounce between 10% and 100%.
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Benjamin Drung <[hidden email]>
| Sat, 10 Oct 2009 22:18:51 +0200
| Subject: [Audacity-devel] cpu usage in Audacity when idle
> On one machine I get a high load, too. I use audacity 1.3.9 on Ubuntu
> 9.04 there. The architecture is amd64 and it's a dual display setup with
> a Nvidia graphic card.
>
> It happens while recording. The load gets back to normal if I minimize
> audacity and switch to another application.

That's the exact opposite of what I see on 9.04 here. Audacity uses
about get 35% of my CPU when recording, but it makes no difference
whether Audacity is minimised or not. If I stop recording, minimise
Audacity then task switch away it, it will start to consume more and
more CPU, but revert to using about 5% of CPU as soon as I task switch
back to it.    

Bill said:
> On a Mac G5 dual 2 GHz, single monitor, Audacity 1.3.9 does not  
> consume excess CPU time when idle (< 2%), but, if I bring up the  
> screenshot window CPU load will bounce between 10% and 100%.

Don't see that on either Win XP or Ubuntu. Screenshot tools makes no
difference to CPU at all except at the moment of taking capturing an
image.



Gale
 

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Saturday 10 October 2009 16:48:10 Al Dimond wrote:

> > >
> > > Yes this was brought up initially on the -users list and was discussed
> > > recently and looked at by Al:
> > > http://n2.nabble.com/Audacity-CVS-consumes-CPU-while-idle-Fedora-12-x86
> > >-6 4-tp3745332p3745332.html
>
> I may have actually seen this since upgrading Kubuntu to 9.10-beta... I
> noticed my load getting unusually high when I had Audacity sitting idle
>  while I was doing something else.  I was more concerned with the other
>  stuff at the time, so I didn't pay much attention.  It went back to normal
>  when I started working on Audacity again.  I'll give this another test
>  now.
>

Well, I might be repro-ing it.  Something weird is going on, at least.  
Audacity has been sitting untouched on another desktop for 20 minutes and its
CPU usage is reading 32%, and has been steadily rising.  But what's odd is
that the load average is not rising with it; it's been close to 0 the whole
time (occasionally rising when I do something else).

I'll give this a more rigorous look on Monday.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Schwendt]

On Sun, 11 Oct 2009 00:07:28 -0600, Al wrote:

> Well, I might be repro-ing it.  Something weird is going on, at least.  
> Audacity has been sitting untouched on another desktop for 20 minutes and its
> CPU usage is reading 32%, and has been steadily rising.  But what's odd is
> that the load average is not rising with it; it's been close to 0 the whole
> time (occasionally rising when I do something else).

Meanwhile, I'm able to reproduce it. Simply by starting Audacity and not
touching it further. It's already reproducible without clicking away the
"Welcome to Audacity" dialog. CPU usage doesn't jump up, but increases
consecutively and _slowly_. I switch the display to another workspace and
then run "top" in a terminal to observe it.

One trick is to _not_ give Audacity focus. Once it gets focus, cpu usage
jumps down. The symptoms smell a bit like something piles up somewhere
(e.g. GUI events) while the window is inactive.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Sunday 11 October 2009 04:04:00 Michael Schwendt wrote:

> On Sun, 11 Oct 2009 00:07:28 -0600, Al wrote:
> > Well, I might be repro-ing it.  Something weird is going on, at least.
> > Audacity has been sitting untouched on another desktop for 20 minutes and
> > its CPU usage is reading 32%, and has been steadily rising.  But what's
> > odd is that the load average is not rising with it; it's been close to 0
> > the whole time (occasionally rising when I do something else).
>
> Meanwhile, I'm able to reproduce it. Simply by starting Audacity and not
> touching it further. It's already reproducible without clicking away the
> "Welcome to Audacity" dialog. CPU usage doesn't jump up, but increases
> consecutively and _slowly_. I switch the display to another workspace and
> then run "top" in a terminal to observe it.
>
> One trick is to _not_ give Audacity focus. Once it gets focus, cpu usage
> jumps down. The symptoms smell a bit like something piles up somewhere
> (e.g. GUI events) while the window is inactive.
>

Yeah, that's exactly what I'm doing.  I left it running like that all night
and top reported CPU usage of 99.9%, CPU0 pegged, and each of the load
averages around 1.5.  Just two Audacity threads.  And when I focused it it
stopped.  It's odd that I can repro it now but couldn't before my dist-
upgrade...

Anyhow, I'm going to try to run it in a profiler.  Unfortunately it seems that
every single profiler package is broken currently in Ubuntu... guess I'll have
to build one.

> ---------------------------------------------------------------------------
> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
>  the only developer event you need to attend this year. Jumpstart your
>  developing skills, take BlackBerry mobile applications to market and stay
>  ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>  http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Sunday 11 October 2009 10:58:01 Al Dimond wrote:

> On Sunday 11 October 2009 04:04:00 Michael Schwendt wrote:
> > On Sun, 11 Oct 2009 00:07:28 -0600, Al wrote:
> > > Well, I might be repro-ing it.  Something weird is going on, at least.
> > > Audacity has been sitting untouched on another desktop for 20 minutes
> > > and its CPU usage is reading 32%, and has been steadily rising.  But
> > > what's odd is that the load average is not rising with it; it's been
> > > close to 0 the whole time (occasionally rising when I do something
> > > else).
> >
> > Meanwhile, I'm able to reproduce it. Simply by starting Audacity and not
> > touching it further. It's already reproducible without clicking away the
> > "Welcome to Audacity" dialog. CPU usage doesn't jump up, but increases
> > consecutively and _slowly_. I switch the display to another workspace and
> > then run "top" in a terminal to observe it.
> >
> > One trick is to _not_ give Audacity focus. Once it gets focus, cpu usage
> > jumps down. The symptoms smell a bit like something piles up somewhere
> > (e.g. GUI events) while the window is inactive.
>
> Yeah, that's exactly what I'm doing.  I left it running like that all night
> and top reported CPU usage of 99.9%, CPU0 pegged, and each of the load
> averages around 1.5.  Just two Audacity threads.  And when I focused it it
> stopped.  It's odd that I can repro it now but couldn't before my dist-
> upgrade...
>
> Anyhow, I'm going to try to run it in a profiler.  Unfortunately it seems
>  that every single profiler package is broken currently in Ubuntu... guess
>  I'll have to build one.
>

Here's what I have so far (to replicate this you need to have debug symbols
for glib).

1. From oprofile I found that almost all of the time is being spent in a glib
function called g_hook_insert_before.  Unfortunately callgraph support wasn't
helping much (perhaps glib was compiled with -fomit-frame-pointer).

2. Here's a stacktrace of a typical g_hook_insert_before() call from gdb:

(gdb) where
#0  IA__g_hook_insert_before (hook_list=0x22351c0, sibling=0x0,
hook=0x23525e0) at /build/buildd/glib2.0-2.22.2/glib/ghook.c:242
#1  0x00007ffff24b9b06 in IA__g_signal_add_emission_hook (signal_id=<value
optimized out>, detail=0, hook_func=0x7ffff6951de0 <event_emission_hook>,
    hook_data=0x0, data_destroy=0) at
/build/buildd/glib2.0-2.22.2/gobject/gsignal.c:939
#2  0x00007ffff6952549 in wxAddEmissionHook () at ../src/gtk/app.cpp:167
#3  wxapp_idle_callback () at ../src/gtk/app.cpp:188
#4  0x00007ffff2212bbe in g_main_dispatch (context=0x1c61920) at
/build/buildd/glib2.0-2.22.2/glib/gmain.c:1960
#5  IA__g_main_context_dispatch (context=0x1c61920) at
/build/buildd/glib2.0-2.22.2/glib/gmain.c:2513
#6  0x00007ffff2216588 in g_main_context_iterate (context=0x1c61920,
block=<value optimized out>, dispatch=<value optimized out>, self=<value
optimized out>)
    at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2591
#7  0x00007ffff22169e5 in IA__g_main_loop_run (loop=0x2250330) at
/build/buildd/glib2.0-2.22.2/glib/gmain.c:2799
#8  0x00007ffff2acc0e7 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.18.2/gtk/gtkmain.c:1216
#9  0x00007ffff696bb48 in wxEventLoop::Run (this=0x224fbe0) at
../src/gtk/evtloop.cpp:76
#10 0x00007ffff69fbec8 in wxAppBase::MainLoop (this=0x1d0a100) at
../src/common/appcmn.cpp:312
#11 0x00007ffff60513bc in wxEntry (argc=<value optimized out>, argv=<value
optimized out>) at ../src/common/init.cpp:460
#12 0x00000000005436f2 in main (argc=1, argv=0x7fffffffe238) at
AudacityApp.cpp:598

3. g_signal_add_emission_hook() calls a macro, g_hook_append, which expands to
calling g_hook_insert_before() with the "sibling" parameter NULL, which causes
it to append.  We appear to be appending to a list of hooks for signal 37,
with name "event" (according to the node structure used in
g_signal_add_emission_hook).  The list of hooks is a linked list, so to append
it must cycle through every hook in the list.  You may see what I'm getting
at.

4. The list of hooks continually expands when Audacity is idle.  After just
several seconds of idling gdb counts 7000 hooks on the list.  All of them
point to the function event_emission_hook(), which for me is in
libwx_gtk2ud_core-2.8.so.0; all of them have ->data == NULL.

5. I set a breakpoint at g_hook_list_clear, but it's never hit.  Rather, these
hooks seem to be reference-counted (when the count hits zero they're removed
from the list).  Reference counts are all set to 1 when the hooks are inserted
into the list; glib source notes that the counterpart to this is a
g_hook_unref() call in g_hook_destroy_link().  g_hook_destroy_link() is
called, in our case, from signal_emit_unlocked_R().  This seems to only happen
when the window has focus.

That's what I have now.  I don't know very much about GTK or wxGTK, though.  
WX seems to continually add emission hooks, but events are not being emitted.  
And seemingly the only problem this causes is that a linked list gets really
long; it doesn't eat much memory (16 bytes per hook... so a modern system
won't really have problems until you make several million of them). I'll look
through some of the relevant wx source and see if I can figure out what's going
on there; it may well be Audacity's fault, but I at least have a function name
in wxGTK to look at that might lead me back.  I'm just posting all this in
case someone with more WX and GTK knowledge can figure it out from here.

 - Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Sounds like you're onto that one Al!  Nice one!

Martyn

Al Dimond wrote:

> On Sunday 11 October 2009 10:58:01 Al Dimond wrote:
>> On Sunday 11 October 2009 04:04:00 Michael Schwendt wrote:
>>> On Sun, 11 Oct 2009 00:07:28 -0600, Al wrote:
>>>> Well, I might be repro-ing it.  Something weird is going on, at least.
>>>> Audacity has been sitting untouched on another desktop for 20 minutes
>>>> and its CPU usage is reading 32%, and has been steadily rising.  But
>>>> what's odd is that the load average is not rising with it; it's been
>>>> close to 0 the whole time (occasionally rising when I do something
>>>> else).
>>> Meanwhile, I'm able to reproduce it. Simply by starting Audacity and not
>>> touching it further. It's already reproducible without clicking away the
>>> "Welcome to Audacity" dialog. CPU usage doesn't jump up, but increases
>>> consecutively and _slowly_. I switch the display to another workspace and
>>> then run "top" in a terminal to observe it.
>>>
>>> One trick is to _not_ give Audacity focus. Once it gets focus, cpu usage
>>> jumps down. The symptoms smell a bit like something piles up somewhere
>>> (e.g. GUI events) while the window is inactive.
>> Yeah, that's exactly what I'm doing.  I left it running like that all night
>> and top reported CPU usage of 99.9%, CPU0 pegged, and each of the load
>> averages around 1.5.  Just two Audacity threads.  And when I focused it it
>> stopped.  It's odd that I can repro it now but couldn't before my dist-
>> upgrade...
>>
>> Anyhow, I'm going to try to run it in a profiler.  Unfortunately it seems
>>  that every single profiler package is broken currently in Ubuntu... guess
>>  I'll have to build one.
>>
>
> Here's what I have so far (to replicate this you need to have debug symbols
> for glib).
>
> 1. From oprofile I found that almost all of the time is being spent in a glib
> function called g_hook_insert_before.  Unfortunately callgraph support wasn't
> helping much (perhaps glib was compiled with -fomit-frame-pointer).
>
> 2. Here's a stacktrace of a typical g_hook_insert_before() call from gdb:
>
> (gdb) where
> #0  IA__g_hook_insert_before (hook_list=0x22351c0, sibling=0x0,
> hook=0x23525e0) at /build/buildd/glib2.0-2.22.2/glib/ghook.c:242
> #1  0x00007ffff24b9b06 in IA__g_signal_add_emission_hook (signal_id=<value
> optimized out>, detail=0, hook_func=0x7ffff6951de0 <event_emission_hook>,
>     hook_data=0x0, data_destroy=0) at
> /build/buildd/glib2.0-2.22.2/gobject/gsignal.c:939
> #2  0x00007ffff6952549 in wxAddEmissionHook () at ../src/gtk/app.cpp:167
> #3  wxapp_idle_callback () at ../src/gtk/app.cpp:188
> #4  0x00007ffff2212bbe in g_main_dispatch (context=0x1c61920) at
> /build/buildd/glib2.0-2.22.2/glib/gmain.c:1960
> #5  IA__g_main_context_dispatch (context=0x1c61920) at
> /build/buildd/glib2.0-2.22.2/glib/gmain.c:2513
> #6  0x00007ffff2216588 in g_main_context_iterate (context=0x1c61920,
> block=<value optimized out>, dispatch=<value optimized out>, self=<value
> optimized out>)
>     at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2591
> #7  0x00007ffff22169e5 in IA__g_main_loop_run (loop=0x2250330) at
> /build/buildd/glib2.0-2.22.2/glib/gmain.c:2799
> #8  0x00007ffff2acc0e7 in IA__gtk_main () at
> /build/buildd/gtk+2.0-2.18.2/gtk/gtkmain.c:1216
> #9  0x00007ffff696bb48 in wxEventLoop::Run (this=0x224fbe0) at
> ../src/gtk/evtloop.cpp:76
> #10 0x00007ffff69fbec8 in wxAppBase::MainLoop (this=0x1d0a100) at
> ../src/common/appcmn.cpp:312
> #11 0x00007ffff60513bc in wxEntry (argc=<value optimized out>, argv=<value
> optimized out>) at ../src/common/init.cpp:460
> #12 0x00000000005436f2 in main (argc=1, argv=0x7fffffffe238) at
> AudacityApp.cpp:598
>
> 3. g_signal_add_emission_hook() calls a macro, g_hook_append, which expands to
> calling g_hook_insert_before() with the "sibling" parameter NULL, which causes
> it to append.  We appear to be appending to a list of hooks for signal 37,
> with name "event" (according to the node structure used in
> g_signal_add_emission_hook).  The list of hooks is a linked list, so to append
> it must cycle through every hook in the list.  You may see what I'm getting
> at.
>
> 4. The list of hooks continually expands when Audacity is idle.  After just
> several seconds of idling gdb counts 7000 hooks on the list.  All of them
> point to the function event_emission_hook(), which for me is in
> libwx_gtk2ud_core-2.8.so.0; all of them have ->data == NULL.
>
> 5. I set a breakpoint at g_hook_list_clear, but it's never hit.  Rather, these
> hooks seem to be reference-counted (when the count hits zero they're removed
> from the list).  Reference counts are all set to 1 when the hooks are inserted
> into the list; glib source notes that the counterpart to this is a
> g_hook_unref() call in g_hook_destroy_link().  g_hook_destroy_link() is
> called, in our case, from signal_emit_unlocked_R().  This seems to only happen
> when the window has focus.
>
> That's what I have now.  I don't know very much about GTK or wxGTK, though.  
> WX seems to continually add emission hooks, but events are not being emitted.  
> And seemingly the only problem this causes is that a linked list gets really
> long; it doesn't eat much memory (16 bytes per hook... so a modern system
> won't really have problems until you make several million of them). I'll look
> through some of the relevant wx source and see if I can figure out what's going
> on there; it may well be Audacity's fault, but I at least have a function name
> in wxGTK to look at that might lead me back.  I'm just posting all this in
> case someone with more WX and GTK knowledge can figure it out from here.
>
>  - Al
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Schwendt]

On Sun, 11 Oct 2009 16:04:32 -0600, Al wrote:

> 3. g_signal_add_emission_hook() calls a macro, g_hook_append, which expands to
> calling g_hook_insert_before() with the "sibling" parameter NULL, which causes
> it to append.  We appear to be appending to a list of hooks for signal 37,
> with name "event" (according to the node structure used in
> g_signal_add_emission_hook).  The list of hooks is a linked list, so to append
> it must cycle through every hook in the list.  You may see what I'm getting
> at.
>
> 4. The list of hooks continually expands when Audacity is idle.  After just
> several seconds of idling gdb counts 7000 hooks on the list.  All of them
> point to the function event_emission_hook(), which for me is in
> libwx_gtk2ud_core-2.8.so.0; all of them have ->data == NULL.

event_emission_hook() would cause the hook to be removed by returning False,
provided it would be called for an event. That's why there is not explicit call
of g_signal_remove_emission_hook() anywhere in the wxGTK source.

What wxGTK src/gtk/app.cpp does in wxapp_idle_callback() isn't clear to me yet
as potentially it can call wxAddEmissionHook() -> g_signal_add_emission_hook()
twice to reinstall an idle handler.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Schwendt]

wxTimer (Audacity uses it a few times) timeout callback runs
wxApp::WakeUpIdle() which in turn runs wxapp_install_idle_handler() which
causes more and more emission hooks to pile up.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Schwendt]

> wxTimer (Audacity uses it a few times) timeout callback runs
> wxApp::WakeUpIdle() which in turn runs wxapp_install_idle_handler() which
> causes more and more emission hooks to pile up.

I've filed a bug report about it,  http://trac.wxwidgets.org/ticket/11315
because AMule is affected by exactly the same problem.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Monday 12 October 2009 09:50:13 Michael Schwendt wrote:
> > wxTimer (Audacity uses it a few times) timeout callback runs
> > wxApp::WakeUpIdle() which in turn runs wxapp_install_idle_handler() which
> > causes more and more emission hooks to pile up.
>
> I've filed a bug report about it,  http://trac.wxwidgets.org/ticket/11315
> because AMule is affected by exactly the same problem.
>

Cool.  My digging through wxGTK source wasn't proving very fruitful.  I came
across some wxPython users having the same problem, and wx_idle_callback was
changed for 2.8.10, so it probably is a new wxGTK bug.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Nice work Al and Michael!  Is there a workaround?

Martyn

Al Dimond wrote:

> On Monday 12 October 2009 09:50:13 Michael Schwendt wrote:
>>> wxTimer (Audacity uses it a few times) timeout callback runs
>>> wxApp::WakeUpIdle() which in turn runs wxapp_install_idle_handler() which
>>> causes more and more emission hooks to pile up.
>> I've filed a bug report about it,  http://trac.wxwidgets.org/ticket/11315
>> because AMule is affected by exactly the same problem.
>>
>
> Cool.  My digging through wxGTK source wasn't proving very fruitful.  I came
> across some wxPython users having the same problem, and wx_idle_callback was
> changed for 2.8.10, so it probably is a new wxGTK bug.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Monday 12 October 2009 15:41:56 Martyn Shaw wrote:
> Nice work Al and Michael!  Is there a workaround?
>

It sounds like perhaps if we caused an event to fire periodically while idle
that could fix it.  I don't know how to do that or if it's feasible... we'd
want to surround anything like that with a pretty restrictive test on wxGTK
version I think.  The wx guys just committed a fix, but, of course, it won't be
released immediately and may not be out to all users for a while.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Schwendt]

On Tue, 13 Oct 2009 11:16:44 -0600, Al wrote:

> On Monday 12 October 2009 15:41:56 Martyn Shaw wrote:
> > Nice work Al and Michael!  Is there a workaround?
> >
>
> It sounds like perhaps if we caused an event to fire periodically while idle
> that could fix it.  I don't know how to do that or if it's feasible...

Perhaps generating an extra event for each wxTimerEvent might avoid it.
It would not "fix" any of the other affected applications, though.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Richard Ash (audacity-help)]

On Mon, 2009-10-12 at 11:42 +0200, Michael Schwendt wrote:

> > 4. The list of hooks continually expands when Audacity is idle.  After just
> > several seconds of idling gdb counts 7000 hooks on the list.  All of them
> > point to the function event_emission_hook(), which for me is in
> > libwx_gtk2ud_core-2.8.so.0; all of them have ->data == NULL.
>
> event_emission_hook() would cause the hook to be removed by returning False,
> provided it would be called for an event. That's why there is not explicit call
> of g_signal_remove_emission_hook() anywhere in the wxGTK source.
>
> What wxGTK src/gtk/app.cpp does in wxapp_idle_callback() isn't clear to me yet
> as potentially it can call wxAddEmissionHook() -> g_signal_add_emission_hook()
> twice to reinstall an idle handler.

To wrap this up I've added an entry to the Known Issues page linking to
the wxGTK bug, and with a note on how to patch wxGTK 2.8.10 to contain
the fix (which is pretty straightforward):
  http://wiki.audacityteam.org/index.php?title=Known_Issues

This gives us somewhere to point other reports of this to - it can only
be fixed by rebuilding wxGTK packages, but doing so will fix all
affected applications.

This seems to be working fine for me when I tried it.

Richard


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel