kicad-developers team mailing list archive

[Raúl Sánchez Siles <rss@...>]

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 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 
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,

-- 
Raúl Sánchez Siles