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 application. 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): XFree86-Mesa-libGL-4.3.0-29 How reproducible: Every time Steps to Reproduce: 1. Install Seven with Mesa and tkinter. 2. Install vtk. I built and installed from the SRPM at: http://www.creatis.insa-lyon.fr/vtk/ 3. Run the doc/test_vtk.py script from MayaVi-1.2 (http://mayavi.sf.net) To verify the library, run using: gdb python gdb> r test_vtk.py Click OK on dialog boxes until the crash. gdb> bt Actual results: 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.. Expected results: Additional info: 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. $ pwd /home/michael/source/MayaVi-1.2/doc $ 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 is available... 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 (gdb) bt #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() () from /usr/lib/vtk/libvtkRendering.so #4 0x03aee60b in vtkXOpenGLRenderWindow::Initialize() () from /usr/lib/vtk/libvtkRendering.so #5 0x03aeebeb in vtkXOpenGLRenderWindow::Start() () from /usr/lib/vtk/libvtkRendering.so #6 0x03ad426a in vtkXRenderWindowInteractor::Initialize() () from /usr/lib/vtk/libvtkRendering.so #7 0x07d0dcdf in PyVTKClass_vtkWorldPointPickerNew () from /usr/lib/vtk/python/libvtkRenderingPython.so #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 (gdb)
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 OpenGL performance. Hope this helps shed some light on the problem if my theory is correct. Thanks.
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: Bug Fixes: - 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.