kicad-developers team mailing list archive

["Tim Hanson" <sideskate@...>]

Hi Raúl

>From my (much smaller) investigation, I think that the 100% CPU load
is somehow related to cross-probing, and the associated
signals/function calls that are used to implement this. The
g_io_unix_prepare possibly is involved in cross-probing... However, I
cannot seem to duplicate the problem now, and it does not occur in the
release builds (I think).

Tim

On Mon, Apr 21, 2008 at 12:06 PM, Raúl Sánchez Siles <rss@...>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 mainglib
> 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 andI
> could report whatever problem I may find on it more easily.
>
> Regards,
>
> --
> Raúl Sánchez Siles
>