glXDestroyContext causes segmentation fault with Via Unichrome graphics

[KarlRelton]

Binary package hint: libgl1-mesa-glx

On a machine with Via Unichrome graphics, run the program glxinfo (from package mesa-utils). It prints the normal info about the GL/GLX availability on the machine, and then gives a segmentation fault (before printing info about the visual).

Putting in some debug comments in the code for glxinfo reveals that it dies on the call to glXDestroyContext, i.e. at line 494 of glxinfo.c of the mesa-utils source code. The function glXDestroyContext is in libGL.so, which comes (I believe) from the libgl1-mesa-glx package, hence I am assigning to this package.

On other machines (with other graphics) glxinfo runs normally - so it is some interaction (or lower level call) specific to the Via Unichrome graphics driver.

Note I am convinced that this bug is the cause of bug https://bugs.launchpad.net/ubuntu/+source/wine/+bug/68761
where wine is crashing/locking up. Wine tests the availability of opengl, by doing pretty much what glxinfo does - creates a context, tests some parameters, and then destroys it with glXDestroyContext. The call to glXDestroyContext again gives a segmentation fault - only in the case of wine this leads to a runaway process and the appearance of a frozen X11 session. For more info leading to this conclusion, please see wine upstream bug report http://bugs.winehq.org/show_bug.cgi?id=11050. Note how the wine team have closed this as invalid, because the fix needs to be in the world of libGL (or possibly in the Unichrome driver).

I'm not quite sure where to go to report to the upstream authors of libGL, so I thought I would at least report it here.

Regards
Karl

[Timo Aaltonen (tjaalton)]

Are you using the via or openchrome driver? We are probably going to default to openchrome for hardy, so it needs testing to support the decision making. So please test hardy with openchrome.

[KarlRelton (karllinuxtest-relton)]

I should add that I can run glxgears, play ppracer, and watch 3D screensavers to my heart's content. In other words 3D graphics on the Via Unichrome are working fine - its only on a glxDestroyContext that things go wrong.

[KarlRelton (karllinuxtest-relton)]

I've tested using Hardy Alpha-3 LiveCD. It boots up okay, and looking at the Xorg.log I see that X uses the openchrome driver.

glxinfo then runs ok - completes with no segmentation fault.

So yes, using the openchrome driver fixes this problem - so I guess you can mark this bug as fixed in the Hardy release.

Note though that glxinfo (and glxgears) do print message that I haven't investigated whent they start:

do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.

Also I notice in glxgears and on preview of the various 3D screensavers that moving the mouse over the display area creates a distortion - so this driver has problems of its own. If that is not a known bug then let me know what package to file against and I'll happily open a new bug specifically for that.

[KarlRelton (karllinuxtest-relton)]

I think the moving mouse-distorts-picture bug is the same as
http://www.openchrome.org/trac/ticket/130

[Timo Aaltonen (tjaalton)]

Excellent, don't hesitate to file new bugs against mesa/x-x-v-openchrome in the future if you find any. Closing this one, thanks.