Pcbnew: crash when deleting a track

[Jacobo Aragunde Pérez]

Application: KiCad
Version: (2013-01-27 BZR 3925)-testing
Build: wxWidgets 2.8.12 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.4,compatible with 2.6)
Platform: Linux 3.7.4-204.fc18.x86_64 x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.49.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=OFF
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

Pcbnew crashes when pressing 'supr' while hovering over a track. This only happens under certain conditions:
* DEBUG has to be enabled.
* Pcbnew has to be launched from KiCad launcher.

[Jacobo Aragunde Pérez (jaragunde)]

The UI gets frozen when manipulating std::cout directly, it looks like pcbnew process cannot access to cout when it was launched from the launcher. Using printf fixes the issue.

[Dick Hollenbeck (dickelbeck)]

On Jan 29, 2013 3:50 AM, "Jacobo Aragunde Pérez" <email address hidden>
wrote:
>
> The UI gets frozen when manipulating std::cout directly, it looks like
> pcbnew process cannot access to cout when it was launched from the
> launcher. Using printf fixes the issue.

This is the pipe going back to the launcher getting full, and causing
pcbnew to block on the full pipe. Stdout is stdout, printf is not a fix.
Reading the other end of the pipe would be a fix.

>
> ** Patch added: "1108717.patch"
>
https://bugs.launchpad.net/kicad/+bug/1108717/+attachment/3505540/+files/1108717.patch
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1108717
>
> Title:
> Pcbnew: crash when deleting a track
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1108717/+subscriptions

[Jacobo Aragunde Pérez (jaragunde)]

If this is just an informative debug message (it looks like that), using a non-blocking output function would just do the trick without adding more code. A different case is when this output is input to another program (could be that eeschema uses it for backwards annotation?).

Can somebody confirm which is the case?

More context: the conflicting line is (at PCB_EDIT_FRAME::Remove_One_Track):

        D( std::cout << __func__ << ": track " << tracksegment << " status=" \
                     << TO_UTF8( TRACK::ShowState( tracksegment->GetState( -1 ) ) ) \
                     << std::endl; )

It prints messages like this one:

Remove_One_Track: track 0x29e1170 status=

[Dick Hollenbeck (dickelbeck)]

On 01/29/2013 09:20 AM, Jacobo Aragunde Pérez wrote:

Jacobo,

This is a duplicate bug report. It was first reported about 4 years ago.

We live with it, the solution has been discussed 5 times.

Again by me this morning.

I like to use printf() for debug output, although I did write this code using std:cout.

Somebody else uses something else for debug output. Debug output goes away on a Release
build.

The best thing you can do short term is to not run the Debug build under kicad, but always
from the command prompt.

> If this is just an informative debug message (it looks like that), using
> a non-blocking output function would just do the trick without adding
> more code. A different case is when this output is input to another
> program (could be that eeschema uses it for backwards annotation?).
>
> Can somebody confirm which is the case?
>
>
> More context: the conflicting line is (at PCB_EDIT_FRAME::Remove_One_Track):
>
> D( std::cout << __func__ << ": track " << tracksegment << " status=" \
> << TO_UTF8( TRACK::ShowState( tracksegment->GetState( -1 ) ) ) \
> << std::endl; )
>
> It prints messages like this one:
>
> Remove_One_Track: track 0x29e1170 status=
>

[Jacobo Aragunde Pérez (jaragunde)]

Hi Dick, I couldn't find the previous bug report, sorry for the dupe.

In any case this is not a big issue since it only affects developers. Users are supposed to use a release build and I can live with it too :D

Thanks for your time.

[Dick Hollenbeck (dickelbeck)]

On 01/30/2013 02:45 AM, Jacobo Aragunde Pérez wrote:
> Hi Dick, I couldn't find the previous bug report, sorry for the dupe.
>
> In any case this is not a big issue since it only affects developers.
> Users are supposed to use a release build and I can live with it too :D

Knowledge of the bug is stored in distributed wet storage, consisting now partly of your
brain also.

Please help watch for it arising again, it does every 6 months or so. Next time you can
help deliver the message.

If we move to a single process model, the pipe goes away. But I repeat myself.

[Dick Hollenbeck (dickelbeck)]

> Knowledge of the bug is stored in distributed wet storage, consisting now partly of your
> brain also.
a.k.a. folklore

Mailing list too.