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@...>
Thu, 24 Apr 2008 16:08:46 +0200
Hello Dick and thanks for you much clarifying anwer:
El Martes, 22 de Abril de 2008, Dick Hollenbeck escribiÃ³:
> 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
> 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.
You are quite right in your assumptions. That quite looks like the problem.
I've found a "simple" workaround for this: once you run eeschema (or any
other) from kicad project manager then look for eeschema pid and
cat /proc/<pid>/0 after that you'll see a lot of debug output and eeschema
will behave normally.
So far I think I've discovered what's exactly happenning: on
common/gestfich.cpp line 536 wxExecute is invoked. With this, kicad is forked
and its child will run eeschema. What happens is that child (eeschema) stdin
and stdout are redirected to some pipes which I'm not sure where they point,
maybe to father kicad process which doesn't handle them and hence the hog.
This is like you suggested.
I'm thinking of a solution which would involve using a wxProcess variableto
redirect pipes into it or something like that. I'm doing some tests and
preparing a patch for this, so I get this working you'll have news about it.
If I'm right I think this isn't a problem only covering debug builds, but
also general builds as long as the child process output enough information,
so it's something where care should be taken.
Thanks for the help, regards,
RaÃºl SÃ¡nchez Siles
--nextPart2982534.b8hVFh8zLk Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
[Attachment content not displayed.] --nextPart2982534.b8hVFh8zLk--