Bug 249195

Summary:	vtk using libOSmesa seg-fault on i915_dri
Product:	[Fedora] Fedora	Reporter:	Ed Hill <ed>
Component:	mesa	Assignee:	Adam Jackson <ajax>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	axel.thimm
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-08-12 15:58:05 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ed Hill 2007-07-22 13:11:56 UTC

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

Comment 1 Ed Hill 2007-07-22 15:25:16 UTC

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.

Comment 2 Adam Jackson 2007-08-06 18:45:27 UTC

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 3 Axel Thimm 2007-08-08 09:23:21 UTC

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?

Comment 4 Ed Hill 2007-08-08 13:19:32 UTC

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?

Comment 5 Axel Thimm 2007-08-08 15:50:59 UTC

(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 :)

Comment 6 Ed Hill 2007-08-12 15:58:05 UTC

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.