pcbnew crashes when 3D Display is selected

Same here (bug 648311) on amd64 and intel graphics.

My pcbnew command line output mirrors the one provided for bug 648311. I also have an intel chipset. Commenting here since the other bug has been marked as a dupe.

On Sun, 26 Sep 2010, Dave wrote:

> Public bug reported:
>
> Selecting "3D Display" from the pcbnew menus causes pcbnew to crash
> immediately. See command-line output below.
>
> dave@dave-laptop:~$ pcbnew
> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.

Sadly that's a known issue... it seems some kind of problem in wx. In
fact, the only GPUs that works are nvidia ones...

--
Lorenzo Marcantonio
Logos Srl

If there's no way to solve this issue on non-NVIDIA hardware, could a more graceful failure be implemented that won't crash the program?

Lorenzo,
Is not a wx problem, is a bad OpenGL implementation: Z buffer is one of the OpenGL's buffers.
I think that this could be tagged as platform bug, driver related : https://bugzilla.redhat.com/show_bug.cgi?id=539764

--
Marco

On 09/28/2010 12:14 PM, Marco Serantoni wrote:
> Lorenzo,
> Is not a wx problem, is a bad OpenGL implementation: Z buffer is one of the OpenGL's buffers.
> I think that this could be tagged as platform bug, driver related : https://bugzilla.redhat.com/show_bug.cgi?id=539764
>
> --
> Marco
>
> ** Bug watch added: Red Hat Bugzilla #539764
> https://bugzilla.redhat.com/show_bug.cgi?id=539764
>

I had this problem also on Fedora 13 on a NVidia card under linux !
After some time I upgraded the system and the it worked again because in
the system update there was also a package OpenGL update.

Jerry

I have the same problem, I use openSUSE 11.3 (KDE 4.4), KiCAD Build: (2010-04-06 SVN 2508)-final wxWidgets 2.8.10 Unicode on 32 Bits GNU/Linux.

Ohh, I forgot:

Ferdinand@linux-4uxh:~> pcbnew
The program 'pcbnew' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 67666 error_code 9 request_code 136 minor_code 8)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

II found a fix for this against the Ubuntu maverick package.

Basically, the bug is that you can't call SwapBuffers(); on a GL visual which is not double buffered. On some hardware, it seems the driver is giving out non double-buffered visuals since KiCad isn't asking for one explicitly.

My fix was twofold..

1. Change the #ifdef checks for WX widgets 2,9,0 to wx widgets 2,8,0. The newer API does appear present in the WxWidgets I have here, which alleges to be 2.8

Secondly, request a double buffered visual. I'll attach the patch for testing shortly..

Attempted fix "works for me".

Probably not robust in the Pre 2.8.0 WxWidgets versions, as you will still die a horrible death if you call SwapBuffers(); when you don't happen to have a double buffered visual.

The behaviour is strange, and probably WxWidgets fault anyway, as the docs DO state that when specifying no arguments to the GLCanvas constructor you are supposed to get RGBA and DOUBLEBUFFER for free.

Whatever.. (This has to be super-helpful enough anyway, especially coming from a gEDA develoepr ;))

Also, note that the crash can be reproduced in the GLCanvas example code here:

http://wiki.wxwidgets.org/WxGLCanvas#wxGLCanvas_sample

It is probably due to the fact the arguments passed to their BasicGLPane class weren't passed on to the wxGLCanvas constructor.

Peter,

The patch did not apply to the bazaar testing branch. Attached is a re-based version, re-based on testing. I tried it, but it did not work. I have wxWidgets 2.8 so this was a good version to test the patch against.

So I did not commit it.

Something is still not right.

Dick

Don't know if this is the same or a different bug. I have NVIDIA hardware and am on Ubuntu Lucid x86_64.

Text of crash, found on console, and pcbnew was started on the command line:

--------------------------------------------
The program 'pcbnew' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadDrawable'.
  (Details: serial 428190 error_code 146 request_code 135 minor_code 11)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
----------------------------------------------
Dick

Looks like a similar crash, although I'm on intel graphics with opensource drivers.

Are you using the Mesa or propriatory drivers??

The patch you applied looks fine, but there could be other issues at work regarding what KiCad wants from its GL visual, and what it gets "by accident".

Try commenting out the SwapBuffers(); call and see if that fixes it. It is at the bottom of the
 Pcb3D_GLCanvas::Redraw() Function in 3d_draw.cpp

If that avoids the crash, I guess you still need to look at why you're not getting a double-buffered visual on your system.

Also, check glxinfo shows you some double-buffered visuals. I can't imagine you wouldn't have some usable double-buffered visuals though.

Also, @Dick.. try the simple canvas example code here:

http://wiki.wxwidgets.org/WxGLCanvas#wxGLCanvas_sample

To see if that works or crashes for you. Then, edit main.cpp and change the constructor for the subclassed wxGLCanvas to pass "args" rather than "0" to the wxGLCanvas constructor.

Peter,

I was out of town. What I failed to mention is that without the patch, my system does not crash and works fine. With the patch it crashes. So it is not clear to me what I am trying to fix, or if my machine is the best one to use to test this patch further.

I can try the things you suggest to get the patch working, but I am not having a problem and it is not a high priority. I had simply offered originally to test your patch, and at this point it is worse than nothing on my system.

Suggestions?

Dick

No idea I'm afraid.. I wonder if I missed specifying some default attributes when I started to request them explicitly. Clearly there is something odd going on here, and with different behaviours on different GL drivers.

> I wonder if I missed specifying some default
> attributes when I started to request them explicitly.
Careful reading required:

{WX_GL_RGBA, WX_GL_DOUBLEBUFFER, WX_GL_DEPTH_SIZE, 16, 0};

The attribute list above, which is a duplication of the one from here:

   http://wiki.wxwidgets.org/WxGLCanvas#wxGLCanvas_sample

causes the patched pcbnew to abort in the exact same way.

Yet the wxGLCanvas_sample does run fine.

This tends to draw attention away from the attribute list towards the
technique used in the constructor.

Dick

BasicGLPane::BasicGLPane(wxFrame* parent, int* args) :
    wxGLCanvas(parent, wxID_ANY, 0, wxDefaultPosition, wxDefaultSize, wxFULL_REPAINT_ON_RESIZE)

Found a deficiency in the example.

Look the example code in wxGLCanvas_sample is bad. It does not even use the attribute list.
Somebody left a hole in their example.

No conclusions can be reached about our attribute list, it could be inadequate.

Dick

For who has radeon, could follow the indications in this bug report ?

http://bugs.freedesktop.org/show_bug.cgi?id=25838

[...]
If I boot with radeon.modeset=0, the application runs (but not well, always on
top of everything)
[...]

More infos:
https://wiki.ubuntu.com/X/KernelModeSetting

@Dick:I had to patch their example, see comment #15.

In my case, with their (broken?) example code which does not pass args, I get a crash. When I pass args, it works fine. Does it work or crash when you patch it to pass args?

Le jeudi 4 novembre 2010 20:44:01, vous avez écrit :
> For who has radeon, could follow the indications in this bug report ?
>
> http://bugs.freedesktop.org/show_bug.cgi?id=25838
>
> [...]
> If I boot with radeon.modeset=0, the application runs (but not well, always
> on top of everything)
> [...]

https://bugs.launchpad.net/kicad/+bug/582997/comments/3

Peter,

The constructor modification to the example,

  http://wiki.wxwidgets.org/WxGLCanvas#wxGLCanvas_sample

passing args to wxGLCanvas::wxGLCanvas() did indeed work OK on my system.

And yet these same attributes when used in a modification to your patch cause the abort on my system.

Suggest going over the differences in technique between our code and the example now, and to review the setup documentation again. The wx docs say to use a different technique for wx previous to 2.7, i.e. 2.6.x.

We can probably rely on a test within CMake scripts to excluded 2.6.x series though.

I am assuming the problem is still related to construction and setup, but it may not be.

Dick

I am not seeing this problem any more in release 2011-03-30 for Ubuntu 10.10. Works on my Intel motherboard and IBM thinkpad.

However, components do not show up because the library was created in Windows, and as such, the path to the 3d model is module\packages3d vs module/packages3d.