kicad-developers team mailing list archive
Mailing list archive
Re: Infinite look taking 100% cpu when building debug mode.
Raúl Sánchez Siles <rss@...>
Mon, 21 Apr 2008 18:06:41 +0200
El Lunes, 21 de Abril de 2008, RaÃºl SÃ¡nchez Siles escribiÃ³:
> El Viernes, 18 de Abril de 2008, Dick Hollenbeck escribiÃ³:
> > > I'd appreciate some clarification.
> > Yes, ditto. You have not said anything about wxWidgets version or
> > operating system.
> I'm very sorry about this, you are right. I wrote the e-mail too fast.
> I'm running Debian lenny with linux-18.104.22.168. I built kicad using wxWidgets
> 22.214.171.124.2 maybe a little old. gtk 2.12.9 and glib 2.16.3.
I forgot to say I'm running 64 bits which may be relevant.
> > I don't believe this is happening here for me, at least it is not
> > noticable. I use Ubuntu Gutsy with wxWidgets 2.8.4 and I run the debug
> > build about 50% of the time.
> Provided this, I'll try building against a newer wxwidgets, 126.96.36.199 most
> probably. I'll see what it happens.
I've used wxwidgets 188.8.131.52 and same problem appeared again. This is the top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13567 rasasi 20 0 168m 26m 14m R 94 2.1 7:11.57 eeschema
> > In your case, the stack trace is not necessarily telling you where the
> > execution is when the cpu is hogging idle time. But given the stack
> > trace, it looks like it is clearly in wxWidgets. That would make sense
> > because that is where the event dispatcher is.
This is a newer backtrace, apparently same as before. This time I build
using latest svn as of today plus wxWdigets 2.8 as stated before:
#0 0x00002ae3e64b52ff in poll () from /lib/libc.so.6
#1 0x00002ae3e4bee104 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#2 0x00002ae3e82be1e6 in g_main_context_iterate (context=0x89e5b0, block=1,
dispatch=1, self=<value optimized out>)
#3 0x00002ae3e82be657 in IA__g_main_loop_run (loop=0x11d4520)
#4 0x00002ae3e6ca1b63 in IA__gtk_main ()
#5 0x00002ae3e4c05eed in wxEventLoop::Run ()
#6 0x00002ae3e4c9845b in wxAppBase::MainLoop ()
#7 0x00000000005603a9 in WinEDA_App::OnRun ()
#8 0x00002ae3e4740e5c in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#9 0x00000000004bb1da in main ()
Run till exit from #0 0x00002ae3e64b52ff in poll () from /lib/libc.so.6
[Switching to Thread 0x2ae3ebf4e6c0 (LWP 13567)]
0x00002ae3e4bee104 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
Run till exit from #0 0x00002ae3e4bee104 in ?? ()
0x00002ae3e82be1e6 in g_main_context_iterate (context=0x89e5b0, block=1,
dispatch=1, self=<value optimized out>)
2951 /tmp/buildd/glib2.0-2.16.3/glib/gmain.c: No such file or directory.
Run till exit from #0 0x00002ae3e82be1e6 in g_main_context_iterate
(context=0x89e5b0, block=1, dispatch=1, self=<value optimized out>)
2849 in /tmp/buildd/glib2.0-2.16.3/glib/gmain.c
Value returned is $1 = 0
Run till exit from #0 IA__g_main_loop_run (loop=0x11d4520)
> > Why don't you ask on one of the wxWidgets mailing lists about this and
> > then get back to us with your findings.
I'll reviewed the mailing list archives, and I plan to write soonish whenI
have the necessary knowledge to post anything meaningful there.
For the moment, this is what I have discovered:
Â· If I run eeschema on its own, then the cpu load doesn't happen.
Â· If I run kicad and then eeschema from there, the high cpu load happens
again, but if I send a stop signal to kicad, the cpu load goes down, but
eeschema is irresponsible.
Â· Analysing eeschema program execution on gdb I've found that the main glib
event loop produces the load, possibly because instead of sleeping or
yielding it have continuously some event to process.
Â· I have suspicions on 2 event types causing this which maybe are related
somehow: redrawing and some kind of I/O(possibly network I/O, i.e.: sockets)
Â· I suspect of redrawing because when I step into the event loop I pass
through _gdk_event_queue_find_first, gdk_event_prepare and gdk_check_xpending
functions of gtklib.
Â· I suspect of I/O because I pass through g_io_unix_prepare and
Supporting this latter I've found in the wx-users ML archives this thread
which doesn't look exactly the same, but related  
I've tried to prove this doing some modifications on the code, without sheer
knowledge of what I was doing.
I've commented these lines on schframe.cpp
COMMON_EVENTS_DRAWFRAME EVT_SOCKET( ID_EDA_SOCKET_EVENT_SERV,
EVT_SOCKET( ID_EDA_SOCKET_EVENT, WinEDA_DrawFrame::OnSockRequest )
Also tried commenting:
if( CreateServer( m_SchematicFrame, KICAD_SCH_PORT_SERVICE_NUMBER ) )
// RemoteCommand is in controle.cpp and is called when PCBNEW
// sends EESCHEMA a command
SetupServerFunction( RemoteCommand );
And adding traces to WinEDA_DrawFrame::OnSockRequest and
WinEDA_DrawFrame::OnSockRequestServer on eda_dde.cpp
Each of these test have been carried out independently and all of them
Maybe any of this appreciations are meaningful to you and you get some
indication of where the problem may be. This isn't a very important problem,
but looks like it's not only me that suffers it. It would be good if I would
be able to run debug version of kicad since I usually run latest svn and I
could report whatever problem I may find on it more easily.
RaÃºl SÃ¡nchez Siles