kicad-developers team mailing list archive
Mailing list archive
Re: Infinite look taking 100% cpu when building debug
Dick Hollenbeck <dick@...>
Tue, 22 Apr 2008 07:29:56 -0500
Thunderbird 22.214.171.124 (X11/20080227)
From previous experience I know that if there are any printf()s or
std:cout << type code left in the build, then you cannot run eeschema or
pcbnew under the kicad project manager.
I would call this code "output to stdout" type code. It should only
be enabled in the debug build, but occasionally we mess up and leave it
in there in the release builds.
Here is my comment from near line 249 of pcbnew/files.cpp, but this
comment is relevant to any outputting to stdout. Also we should be
aware that the problem does not come on immediately, but only after the
pipe is full. Any combination of printf() or std:cout << will
contribute to filling the pipe, and in any child process of kicad,
eeschema or pcbnew.
// note this freezes up pcbnew when run under the kicad project
// manager. runs fine from command prompt. This is because the kicad
// project manager redirects stdout of the child pcbnew process to
// but never reads from that pipe, and that in turn eventually blocks
// the pcbnew program when the pipe it is writing to gets full.
// Output the board object tree to stdout, but please run from
m_Pcb->Show( 0, std::cout );
This may be what you are running into. I discovered this about 6
months ago. What it also means is that no one should expect to be able
to run a debug build in the normal way, i.e. pcbnew or eeschema running
as a child of the kicad project manager. The debug builds must be run
from the command prompt. And of course that is the only way you can
actually see the printf()s anyway.
Sánchez Siles wrote:
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
I'm very sorry about this, you are right. I wrote the e-mail too fast.
I'm running Debian lenny with linux-126.96.36.199. I built kicad using wxWidgets
188.8.131.52.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, 184.108.40.206 most
probably. I'll see what it happens.
I've used wxwidgets 220.127.116.11 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 when I
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.
I pray we can elect a U.S. President that has the common sense to enforce our
existing immigration laws and stop the invasion from Mexico.