kicad-developers team mailing list archive

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

Hello Dick and thanks for you much clarifying anwer:

El Martes, 22 de Abril de 2008, Dick Hollenbeck escribió:
> 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.
>

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