Red Hat Bugzilla – Bug 249195
vtk using libOSmesa seg-fault on i915_dri
Last modified: 2007-11-30 17:12:10 EST
Description of problem: All VTK programs that I use (both C++ and python scripts) seg-fault. Version-Release number of selected component (if applicable): vtk-5.0.3-18.2.fc6.x86_64 How reproducible: 100% Steps to Reproduce: 1. run any vtk app (including python scripts) 2. watch it seg-fault 3. Additional info: Hi folks, I've been using locally-built versions of Axel's VTK RPMs for some months and they've worked nicely. I recently yum update-d my FC6-x86_64 laptop to the latest vtk as shipped in Fedora and all vtk- using applications now seg-fault somewhere inside the /usr/lib64/dri/i915_dri.so lib provided by mesa-libGL-6.5.1-9.fc6.x86_64. A back-trace is included below. I don't understand what's going wrong here. Can anyone suggest fixes? I think the only difference between my local builds and the FC-6 version of vtk is the inclusion of -DVTK_OPENGL_HAS_OSMESA:BOOL=ON in the Fedora-provided FC-6 builds. Is there anything else I can do to help debug this? Here's the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912560347600 (LWP 22395)] 0x00002aaaae8680e6 in intelInitDriverFunctions () from /usr/lib64/dri/i915_dri.so (gdb) bt #0 0x00002aaaae8680e6 in intelInitDriverFunctions () from /usr/lib64/dri/i915_dri.so #1 0x00002aaaad28682e in _mesa_make_current () from /usr/lib64/libOSMesa.so.6 #2 0x00002aaaae8679d9 in intelMakeCurrent () from /usr/lib64/dri/i915_dri.so #3 0x00002aaaae84fd83 in __driUtilUpdateDrawableInfo () from /usr/lib64/dri/i915_dri.so #4 0x0000003fca8213e7 in glXDestroyContext () from /usr/lib64/libGL.so.1 #5 0x0000003fca8235bd in glXMakeCurrentReadSGI () from /usr/lib64/libGL.so.1 #6 0x00002aaaaac610a0 in vtkXOpenGLRenderWindow::MakeCurrent () from /usr/lib64/libvtkRendering.so.5.0 #7 0x00002aaaaac61e3b in vtkXOpenGLRenderWindow::WindowInitialize () from /usr/lib64/libvtkRendering.so.5.0 #8 0x00002aaaaac5edc2 in vtkXOpenGLRenderWindow::Start () from /usr/lib64/libvtkRendering.so.5.0 #9 0x00002aaaaac368c0 in vtkXRenderWindowInteractor::Initialize () from /usr/lib64/libvtkRendering.so.5.0 #10 0x00002aaaaabf103d in vtkRenderWindow::Render () from /usr/lib64/libvtkRendering.so.5.0 #11 0x00002aaaaac5f250 in vtkXOpenGLRenderWindow::Render () from /usr/lib64/libvtkRendering.so.5.0 #12 0x00000000004b6e6e in do_render () #13 0x0000000000413a68 in main () (gdb) The program is running. Exit anyway? (y or n) y
I just installed the vtk packages from updates-testing on an F-7 i386 machine with an ATI M10 chipset (FireGL Mobility T2) and vtk programs (eg. some python scripts) work nicely on it -- no segfaults. So I suppose this bug is some sort of interaction between vtk and the i915_dri bits. I'll try other machines and building VTK with and without OSMesa next to see if that narrows it down.
Oh wow. Symbol resolution conflicts hooray! I'd really like to see if this is reproducable on 6.5.2-6 or later. F7 contained 6.5.2-10 so that'd be a good place to start.
Comment #1 already indicated that the problem vanished on F7, so the check is already done. What would you suggest to do with FC6? Just not build against osmesa?
I don't have the time today but this weekend (at the latest!) I'll install F7-x86_64 on the Dell D820 that triggers this problem. I can verify that locally built VTK rpms that don't include OSMesa work fine so it seems very likely that disabling OSMesa will help the (few?) folks trying to use VTK with the i915_dri driver on FC-6. Other than the move to F7 (which I intended to do anyway) is there anything else (e.g., back-traces or library symbol lists?) that I can do to help pin down this problem?
(In reply to comment #4) > Other than the move to F7 (which I intended to do anyway) is there anything > else (e.g., back-traces or library symbol lists?) that I can do to help pin > down this problem? If you are adventurous enough you could try rebuilding mesa >= 6.5.2-6 on FC6 (for example F7's mesa) and rebuild vtk against that. According to comment #2 this should work then, and maybe ajax would even issue an update for FC6's mesa :)
I installed F7 on the machine that triggered this problem (a Dell Latitude D820 with the "Intel 945GM/GMS, 943/940GML" integrated graphics controller) and the VTK segfaults are now gone -- all the VTK programs I use and write seem to be working as they should. FWIW, I noticed that F7 selected (by default) the "intel" X driver and not the i810 as used in FC6. I'm closing this bug as WORKSFORME. If someone really needs VTK on FC6 with an Intel graphics chipset then please re-open it.