Red Hat Bugzilla – Bug 104386
Last modified: 2015-01-07 19:06:36 EST
Description of problem:
This is going to be a tough one since not all the software is part of redhat
distribution; but I've been having trouble installing graphics packages and
getting them to run via their python wrappers. The problem is that libGL
crashes. I seen the problem with vtk, wxWindows wrappers and PyQt eric3
I've fixed the problem by downloading the 5.0.2 version of MesaLib
(www.mesa3d.org), building as 'make linux', and installing the resulting
libraries in place of the XFree86-Mesa-* libraries. I also had to re-point some
of the libraries and links in /usr/lib/tls and /usr/X11R6/lib/tls.
I also think this is probably related to my video card. It's an Voodoo5 and so
is 'community supported'.
If you redhat guys simply want to close this one out, feel free. I have my
workaround; but you might want to upgrade the Mesa library in your XFree86 packages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Seven with Mesa and tkinter.
2. Install vtk. I built and installed from the SRPM at:
3. Run the doc/test_vtk.py script from MayaVi-1.2 (http://mayavi.sf.net)
To verify the library, run using:
gdb> r test_vtk.py
Click OK on dialog boxes until the crash.
I get a memory fault.
I forgot to capture the backtrace before replacing the libraries. If you need
it, I'll re-install the Redhat RPMS and capture it..
Graphics card is Voodoo5.
I'd need a backtrace from a crash in order to verify this. When running
Mesa in gdb, it will always SEGV on purpose due to CPU detection stuff.
Once that occurs, use "cont" to continue to the real crash.
In order to do this of course, you'll need to completely restore all of the
original Red Hat rpms, symlinks, etc.
OK, I re-installed and here's the traceback from running the Mayavi vtk_test.py
installation. Again, I haven't found a OpenGL program that crashes directly yet.
$ gdb python
GNU gdb Red Hat Linux (5.3post-1.20021129.37rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...
(gdb) r test_vtk.py
Starting program: /usr/bin/python test_vtk.py
(no debugging symbols found)...(no debugging symbols found)...[New Thread
-1084332224 (LWP 7922)]
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...Testing if Tkinter
OK - you have Tkinter
TclVersion = 8.3, TkVersion = 8.3
Testing if VTK can be imported ...
OK, vtkpython found.
Testing if vtkCubeAxesActor2D can be instantiated ...
OK, vtkCubeAxesActor2D can be instantiated.
Testing a sample vtk program. You should see a 300x300 pixel window with a black
background and with a magenta coloured Cone. You can interact with the cone
using the mouse. To quit the test press q on the window. If this test is
successful then the basic vtkpython installation is OK.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084332224 (LWP 7922)]
0x009237e4 in __glXSetupForCommand () from /usr/lib/tls/i686/libGL.so.1
#0 0x009237e4 in __glXSetupForCommand () from /usr/lib/tls/i686/libGL.so.1
#1 0x009200a8 in CreateContext () from /usr/lib/tls/i686/libGL.so.1
#2 0x0092036e in glXCreateContext () from /usr/lib/tls/i686/libGL.so.1
#3 0x03aede81 in vtkXOpenGLRenderWindow::WindowInitialize() ()
#4 0x03aee60b in vtkXOpenGLRenderWindow::Initialize() ()
#5 0x03aeebeb in vtkXOpenGLRenderWindow::Start() ()
#6 0x03ad426a in vtkXRenderWindowInteractor::Initialize() ()
#7 0x07d0dcdf in PyVTKClass_vtkWorldPointPickerNew ()
#8 0x080d1879 in PyCFunction_Call ()
#9 0x0807b140 in PyEval_EvalCode ()
#10 0x0807bcee in PyEval_EvalCodeEx ()
#11 0x0807d1bb in PyEval_GetFuncDesc ()
#12 0x0807b088 in PyEval_EvalCode ()
#13 0x0807bcee in PyEval_EvalCodeEx ()
#14 0x0807d1bb in PyEval_GetFuncDesc ()
#15 0x0807b088 in PyEval_EvalCode ()
#16 0x0807bcee in PyEval_EvalCodeEx ()
#17 0x080788e5 in PyEval_EvalCode ()
#18 0x08098929 in PyRun_FileExFlags ()
#19 0x08097890 in PyRun_SimpleFileExFlags ()
#20 0x080971da in PyRun_AnyFileExFlags ()
#21 0x08053abc in Py_Main ()
#22 0x08053519 in main ()
#23 0x00126678 in __libc_start_main () from /lib/tls/libc.so.6
Can you provide an example from a single threaded C application perhaps?
Debugging multithreaded python or other interpreted languages is painful.
It's not clear if this is a bug in the application, or a bug in part
of the OS.
I'm closing this bug report. I just installed the Severn update from the
up2date channel (which, of course, includes new XFree86-Mesa-* packages) and the
crashes are gone.
I love bugs that 'fix themselves' -- well at least sort of.
Ok, do me a favour if you don't mind testing something...
As root, do:
echo 2 > /proc/sys/kernel/exec-shield
Then try running the application(s) that used to crash. If they begin
crashing again, make note. Then try to echo 1 to that file and try again.
Then try echo 0 and try again.
Please let me know if any of those tests cause your applications to crash
again. If they do crash with any of these tests, then the problem is a
known conflict between DRI and exec-shield which we're working on hopefully
fixing for the final release. If exec-shield is enabled, then DRI is not
useable, as such for the time being at least, users need to either make sure
exec-shield is disabled in order to use DRI, or make sure DRI is disabled
if exec-shield is enabled. The latter will result in slow software-only
Hope this helps shed some light on the problem if my theory is correct.
Everything worked fine no matter what the exec-shield setting.
Did you update to Mesa 4.1 in the latest Severn Beta Update? If so, one of the
items in the ChangeLog from the web site (see http://www.mesa3d.org) was:
- 3dfx/glide driver render-to-window feature was broken
This matches all my tests so far (they have been inside GUI widgets e.g. Tkinter
etc.), not full screen. Maybe it got fixed behind your back.