← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #01451

Re: Infinite look taking 100% cpu when building debug

  Thread Previous • Date Previous • • Thread Next 
Raúl
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 itself, 
// 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 command prompt: 
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. 


Dick




Sánchez Siles wrote:

El Lunes, 21 de Abril de 2008, Raúl Sánchez Siles escribió:


Hello:

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-2.6.24.3. I built kicad using wxWidgets
2.6.3.2.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, 2.8.7.1 most
probably. I'll see what it happens.
I've used wxwidgets 2.8.7.1 and same problem appeared again. This is the top line: 

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: 

(gdb)bt
#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>) 
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2951
#3 0x00002ae3e82be657 in IA__g_main_loop_run (loop=0x11d4520) at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2850 #4 0x00002ae3e6ca1b63 in IA__gtk_main () at /build/buildd/gtk+2.0-2.12.9/gtk/gtkmain.c:1163 #5 0x00002ae3e4c05eed in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #6 0x00002ae3e4c9845b in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0 
#7 0x00000000005603a9 in WinEDA_App::OnRun ()
#8 0x00002ae3e4740e5c in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#9 0x00000000004bb1da in main ()
(gdb) finish
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
(gdb)
Run till exit from #0 0x00002ae3e4bee104 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0 0x00002ae3e82be1e6 in g_main_context_iterate (context=0x89e5b0, block=1, dispatch=1, self=<value optimized out>) 
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2951
2951 /tmp/buildd/glib2.0-2.16.3/glib/gmain.c: No such file or directory.
in /tmp/buildd/glib2.0-2.16.3/glib/gmain.c
(gdb)
Run till exit from #0 0x00002ae3e82be1e6 in g_main_context_iterate (context=0x89e5b0, block=1, dispatch=1, self=<value optimized out>) 
at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2951
IA__g_main_loop_run (loop=0x11d4520) at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2849 
2849 in /tmp/buildd/glib2.0-2.16.3/glib/gmain.c
Value returned is $1 = 0
(gdb)
Run till exit from #0 IA__g_main_loop_run (loop=0x11d4520) at /tmp/buildd/glib2.0-2.16.3/glib/gmain.c:2849 



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 IA__g_io_channel_get_buffer_condition functions.
Supporting this latter I've found in the wx-users ML archives this thread which doesn't look exactly the same, but related [0] [1] 

[0] http://lists.wxwidgets.org/pipermail/wx-users/2007-December/104867.html
[1] http://lists.wxwidgets.org/pipermail/wx-users/2008-March/106653.html
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,
WinEDA_DrawFrame::OnSockRequestServer )
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 without success.
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. 

Regards,





--
Best Regards,

Dick


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.

Follow ups

References

  Thread Previous • Date Previous • • Thread Next