I have noticed that when I leave my application open and let it sit
there idle it slowly begins to consume more and more CPU and memory
over the course of several hours. However when I simply bring the
mouse over it and click on the application it goes back to consuming
almost nothing. I don't have anything running in the background for
this application and can't figure out why leaving it idle for an
extended period of time causes it to consume more and more of the
CPU. I was wondering if anyone has encountered anything like this.
I have noticed that when I leave my application open and let it sit
there idle it slowly begins to consume more and more CPU and memory
over the course of several hours. However when I simply bring the
mouse over it and click on the application it goes back to consuming
almost nothing. I don't have anything running in the background for
this application and can't figure out why leaving it idle for an
extended period of time causes it to consume more and more of the
CPU. I was wondering if anyone has encountered anything like this.
Thanks,
Scott
>
Yes, I have the same problem under linux.
I don't konw why.
So, now I use gvim for the moment ...
I have noticed that when I leave my application open and let it sit
there idle it slowly begins to consume more and more CPU and memory
over the course of several hours. However when I simply bring the
mouse over it and click on the application it goes back to consuming
almost nothing. I don't have anything running in the background for
this application and can't figure out why leaving it idle for an
extended period of time causes it to consume more and more of the
CPU. I was wondering if anyone has encountered anything like this.
Which platform? Do you have any timers or idle event handlers?
The problem is occurring on Linux, but the same application runs on
Windows as well and I am not getting the same problems. I do have
timers and that was the first issue I addressed at trying to solve
this problem. I basically removed the timers and let the application
sit idle and it still slowly consumed more and more CPU. I don't have
any idle events.
···
On Aug 13, 12:01 pm, Robin Dunn <ro...@alldunn.com> wrote:
Scott Hall wrote:
> I have noticed that when I leave my application open and let it sit
> there idle it slowly begins to consume more and more CPU and memory
> over the course of several hours. However when I simply bring the
> mouse over it and click on the application it goes back to consuming
> almost nothing. I don't have anything running in the background for
> this application and can't figure out why leaving it idle for an
> extended period of time causes it to consume more and more of the
> CPU. I was wondering if anyone has encountered anything like this.
Which platform? Do you have any timers or idle event handlers?
--
Robin Dunn
Software Craftsmanhttp://wxPython.org
I did some additional "testing" concerning this problem. I ignored my
application for the moment and went to the wxPython demo directory and
launched a few demos and let them sit open and idle. Most notably I
open the AUI_DockingWindowMgr.py, StyledTextCtrl_2.py, and a few
others. I listed the first two mainly because I am using both in my
application. It seems that only the StyledTextCtrl slowly consumes
the CPU while the others, as expected, do nothing while they are
idle. After letting the StyledTextCtrl run idle and slowly consuming
the CPU I brought the mouse over it and gave it focus and the
consumption of the CPU went back to nothing. Is this a bug with the
StyledTextCtrl? This is only happening for me on Linux, these demos
run fine without the CPU consumption on Solaris and Windows.
Thanks,
Scott
···
On Aug 13, 12:48 pm, Scott Hall <smhall...@gmail.com> wrote:
The problem is occurring on Linux, but the same application runs on
Windows as well and I am not getting the same problems. I do have
timers and that was the first issue I addressed at trying to solve
this problem. I basically removed the timers and let the application
sit idle and it still slowly consumed more and more CPU. I don't have
any idle events.
On Aug 13, 12:01 pm, Robin Dunn <ro...@alldunn.com> wrote:
> Scott Hall wrote:
> > I have noticed that when I leave my application open and let it sit
> > there idle it slowly begins to consume more and more CPU and memory
> > over the course of several hours. However when I simply bring the
> > mouse over it and click on the application it goes back to consuming
> > almost nothing. I don't have anything running in the background for
> > this application and can't figure out why leaving it idle for an
> > extended period of time causes it to consume more and more of the
> > CPU. I was wondering if anyone has encountered anything like this.
> Which platform? Do you have any timers or idle event handlers?
> --
> Robin Dunn
> Software Craftsmanhttp://wxPython.org
On Fri, Aug 14, 2009 at 7:10 AM, Scott Hall<smhall316@gmail.com> wrote:
I did some additional "testing" concerning this problem. I ignored my
application for the moment and went to the wxPython demo directory and
launched a few demos and let them sit open and idle. Most notably I
open the AUI_DockingWindowMgr.py, StyledTextCtrl_2.py, and a few
others. I listed the first two mainly because I am using both in my
application. It seems that only the StyledTextCtrl slowly consumes
the CPU while the others, as expected, do nothing while they are
idle. After letting the StyledTextCtrl run idle and slowly consuming
the CPU I brought the mouse over it and gave it focus and the
consumption of the CPU went back to nothing. Is this a bug with the
StyledTextCtrl? This is only happening for me on Linux, these demos
run fine without the CPU consumption on Solaris and Windows.
Just to add to this I have also noticed this behavior with the STC on
wxMac. Though it stays steady between 2-6% cpu usage when the
application is set idle. I did some stack traces at the time and it
appears to be coming from the stc re-painting itself or part of
itself.
Is there a way to suppress the repainting via code? I have left the
demo running and am seeing the CPU consumption creep into 10% range.
···
On Aug 14, 9:35 am, Cody Precord <codyprec...@gmail.com> wrote:
Hello,
On Fri, Aug 14, 2009 at 7:10 AM, Scott Hall<smhall...@gmail.com> wrote:
> I did some additional "testing" concerning this problem. I ignored my
> application for the moment and went to the wxPython demo directory and
> launched a few demos and let them sit open and idle. Most notably I
> open the AUI_DockingWindowMgr.py, StyledTextCtrl_2.py, and a few
> others. I listed the first two mainly because I am using both in my
> application. It seems that only the StyledTextCtrl slowly consumes
> the CPU while the others, as expected, do nothing while they are
> idle. After letting the StyledTextCtrl run idle and slowly consuming
> the CPU I brought the mouse over it and gave it focus and the
> consumption of the CPU went back to nothing. Is this a bug with the
> StyledTextCtrl? This is only happening for me on Linux, these demos
> run fine without the CPU consumption on Solaris and Windows.
Just to add to this I have also noticed this behavior with the STC on
wxMac. Though it stays steady between 2-6% cpu usage when the
application is set idle. I did some stack traces at the time and it
appears to be coming from the stc re-painting itself or part of
itself.
I did some additional "testing" concerning this problem. I ignored my
application for the moment and went to the wxPython demo directory and
launched a few demos and let them sit open and idle. Most notably I
open the AUI_DockingWindowMgr.py, StyledTextCtrl_2.py, and a few
others. I listed the first two mainly because I am using both in my
application. It seems that only the StyledTextCtrl slowly consumes
the CPU while the others, as expected, do nothing while they are
idle. After letting the StyledTextCtrl run idle and slowly consuming
the CPU I brought the mouse over it and gave it focus and the
consumption of the CPU went back to nothing. Is this a bug with the
StyledTextCtrl? This is only happening for me on Linux, these demos
run fine without the CPU consumption on Solaris and Windows.
Just to add to this I have also noticed this behavior with the STC on
wxMac. Though it stays steady between 2-6% cpu usage when the
application is set idle. I did some stack traces at the time and it
appears to be coming from the stc re-painting itself or part of
itself.
The STC does have a timer that it uses to trigger redrawing the portion of the window where the caret is located, so that would account for the CPU utilization. However I don't see how that would lead to a steadily increasing utilization that then drops when other events are sent... The STC also has an EVT_IDLE handler, although I don't remember right off what it is used for. I'll try to take a closer look at this the next time I am working on STC.
···
On Fri, Aug 14, 2009 at 7:10 AM, Scott Hall<smhall316@gmail.com> wrote:
So I have been watching this issue with the StyledTextCtrl since this
last posting was done. I have left an open editor running throughout
the day and night, without doing anything to it. No mouse hovering,
no interaction of any kind and I have seen it reach up to 98% CPU
consumption simply sitting in its idle state. The percentage goes
back to nothing when I give the editor the focus again. I have
noticed this problem on Linux and Solaris. Windows does not seem to
have this problem. Again I know Robin said he would take a look at
this the next time he visited the STC, but I just want to know if
anyone else has come across this problem with such a high percentage
of CPU consumption.
Thanks
···
On Aug 14, 1:23 pm, Robin Dunn <ro...@alldunn.com> wrote:
Cody Precord wrote:
> Hello,
> On Fri, Aug 14, 2009 at 7:10 AM, Scott Hall<smhall...@gmail.com> wrote:
>> I did some additional "testing" concerning this problem. I ignored my
>>applicationfor the moment and went to the wxPython demo directory and
>> launched a few demos and let them sit open andidle. Most notably I
>> open the AUI_DockingWindowMgr.py, StyledTextCtrl_2.py, and a few
>> others. I listed the first two mainly because I am using both in my
>>application. It seems that only the StyledTextCtrl slowly consumes
>> the CPU while the others, as expected, do nothing while they are
>>idle. After letting the StyledTextCtrl runidleand slowly consuming
>> the CPU I brought the mouse over it and gave it focus and the
>> consumption of the CPU went back to nothing. Is this a bug with the
>> StyledTextCtrl? This is only happening for me on Linux, these demos
>> run fine without the CPU consumption on Solaris and Windows.
> Just to add to this I have also noticed this behavior with the STC on
> wxMac. Though it stays steady between 2-6% cpu usage when the
>applicationis setidle. I did some stack traces at the time and it
> appears to be coming from the stc re-painting itself or part of
> itself.
The STC does have a timer that it uses to trigger redrawing the portion
of the window where the caret is located, so that would account for the
CPU utilization. However I don't see how that would lead to a steadily
increasing utilization that then drops when other events are sent...
The STC also has an EVT_IDLE handler, although I don't remember right
off what it is used for. I'll try to take a closer look at this the
next time I am working on STC.
--
Robin Dunn
Software Craftsmanhttp://wxPython.org
I see this quite often when letting peppy run overnight and returning
in the morning to a 100% utilization.
I'm running a test right now using gdb in an attempt to break the
application to see what routine is using the resources. This presumes
that I can break it at the right spot, however, so I'm compiling
valgrind to use callgrind as a profiler.
Earlier it was mentioned that it might be in the STC repaint code.
Anyone have any more detailed stack traces to share?
Too bad the nature of this bug means having to wait many hours between
attempts...
Rob
···
On Thu, Oct 8, 2009 at 10:24 AM, Scott Hall <smhall316@gmail.com> wrote:
I just want to know if
anyone else has come across this problem with such a high percentage
of CPU consumption.
Update: I was able to attach gdb to the python process containing the
100% CPU usage I got a stack trace of:
#0 0x00007f6e5ef14b6b in g_hook_insert_before ()
from /usr/lib/libglib-2.0.so.0 #1 0x00007f6e5f7f0e93 in g_signal_add_emission_hook ()
from /usr/lib/libgobject-2.0.so.0 #2 0x00007f6e61ff2536 in wxAddEmissionHook () at ../src/gtk/app.cpp:167 #3 0x00007f6e61ff336a in wxapp_idle_callback () at ../src/gtk/app.cpp:188 #4 0x00007f6e5ef204b2 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0 #5 0x00007f6e5ef23795 in ?? () from /usr/lib/libglib-2.0.so.0 #6 0x00007f6e5ef23a8d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #7 0x00007f6e60bc04a2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #8 0x00007f6e620117f3 in wxEventLoop::Run (this=0x2de8c80)
at ../src/gtk/evtloop.cpp:76 #9 0x00007f6e620b440e in wxAppBase::MainLoop (this=0x13b2b90)
at ../src/common/appcmn.cpp:312 #10 0x00007f6e633ec747 in wxPyApp::MainLoop ()
from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
...
but attempting to continue from there resulted in the CPU usage
returning to zero. It's unlikely that I happened to break exactly
where the trouble is, but at least it's another data point.
I think the profiler might be better able to tell where the real
trouble spot is, but haven't been able to get valgrind to print out
anything useful yet.
Rob
···
On Fri, Oct 9, 2009 at 11:26 AM, Rob McMullen <rob.mcmullen@gmail.com> wrote:
I'm running a test right now using gdb in an attempt to break the
application to see what routine is using the resources. This presumes
that I can break it at the right spot, however, so I'm compiling
valgrind to use callgrind as a profiler.
Hi, I have been working on a similar problem in Audacity and noticed
this post in a web search. Audacity uses wxGTK but not Python. I'm
pretty sure we're seeing the same thing: idle app starts consuming
lots of CPU and eventually RAM, then give the app focus and it stops.
I checked it out with oprofile, gdb, and the glib sources. Indeed,
g_hook_insert_before() is where most of the CPU time is being spent.
wxAddEmissionHook(), called from wxapp_idle_callback() every time an
idle event fires, keeps adding emission hooks that don't get cleared
by GTK until something happens. g_hook_insert_before() is actually in
this case inserting a structure at the end of a linked list, and all
that CPU time is spent traversing the list. In just 15 minutes on my
system the list grew to some 240,000 nodes long. I have no idea how
long it got when I left Audacity open overnight... although it didn't
even cause my system to be unresponsive; it probably didn't eat that
much RAM, the list nodes are pretty small.
I'm going to ask wx developers what they think can be done about this,
whether it's a bug in WX or caused by something our apps are doing.
There have been some recent changes to wxapp_idle_callback()... I
don't know whether that's the cause, though, I'm not really all that
knowledgeable about WX or GTK. Just thought I'd let you guys know
what I've found.
···
On Oct 11, 12:35 pm, Rob McMullen <rob.mcmul...@gmail.com> wrote:
On Fri, Oct 9, 2009 at 11:26 AM, Rob McMullen <rob.mcmul...@gmail.com> wrote:
> I'm running a test right now using gdb in an attempt to break the
> application to see what routine is using the resources. This presumes
> that I can break it at the right spot, however, so I'm compiling
> valgrind to use callgrind as a profiler.
Update: I was able to attach gdb to the python process containing the
100% CPU usage I got a stack trace of:
#0 0x00007f6e5ef14b6b in g_hook_insert_before ()
from /usr/lib/libglib-2.0.so.0 #1 0x00007f6e5f7f0e93 in g_signal_add_emission_hook ()
from /usr/lib/libgobject-2.0.so.0 #2 0x00007f6e61ff2536 in wxAddEmissionHook () at ../src/gtk/app.cpp:167 #3 0x00007f6e61ff336a in wxapp_idle_callback () at ../src/gtk/app.cpp:188 #4 0x00007f6e5ef204b2 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0 #5 0x00007f6e5ef23795 in ?? () from /usr/lib/libglib-2.0.so.0 #6 0x00007f6e5ef23a8d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #7 0x00007f6e60bc04a2 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #8 0x00007f6e620117f3 in wxEventLoop::Run (this=0x2de8c80)
at ../src/gtk/evtloop.cpp:76 #9 0x00007f6e620b440e in wxAppBase::MainLoop (this=0x13b2b90)
at ../src/common/appcmn.cpp:312 #10 0x00007f6e633ec747 in wxPyApp::MainLoop ()
from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
...
but attempting to continue from there resulted in the CPU usage
returning to zero. It's unlikely that I happened to break exactly
where the trouble is, but at least it's another data point.
I think the profiler might be better able to tell where the real
trouble spot is, but haven't been able to get valgrind to print out
anything useful yet.
One of the developers has just assined the ticket to himself, so you may want to update that bug report with your findings so he has all the information available.
···
On 10/11/09 11:35 AM, Rob McMullen wrote:
On Fri, Oct 9, 2009 at 11:26 AM, Rob McMullen<rob.mcmullen@gmail.com> wrote:
I'm running a test right now using gdb in an attempt to break the
application to see what routine is using the resources. This presumes
that I can break it at the right spot, however, so I'm compiling
valgrind to use callgrind as a profiler.
Update: I was able to attach gdb to the python process containing the
100% CPU usage I got a stack trace of:
One of the developers has just assined the ticket to himself, so you may
want to update that bug report with your findings so he has all the
information available.