Bug 430471 - qtdemo-qt4 segfault
qtdemo-qt4 segfault
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-28 06:13 EST by Craig Schlenter
Modified: 2009-10-22 08:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-23 14:18:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Craig Schlenter 2008-01-28 06:13:04 EST
Description of problem:

$ qtdemo-qt4 
Segmentation fault

Version-Release number of selected component (if applicable):

qt4-doc-4.3.3-5.fc9.i386

I'd install the debuginfo package but it's 151Megs!! I'm hoping
someone can reproduce this without me having to download that to
get more info.
Comment 1 Rex Dieter 2008-01-28 12:46:52 EST
confirmed (on x86_64). ugh.
Comment 2 Ngo Than 2008-01-28 13:21:33 EST
it seems one of the qt-copy patches caused the crash in Qt!
Comment 3 Rex Dieter 2008-01-28 13:36:54 EST
I tried downgrading to qt4-4.2.3-3.fc9, and I'm still seeing the crash, so that
seems to rule out blaming qt-copy.
Comment 4 Rex Dieter 2008-01-28 13:47:55 EST
I'm installing the gargantuan qt4-debuginfo now, see if we can get a useful trace.
Comment 5 Rex Dieter 2008-01-28 13:55:47 EST
If I'm reading this right, this may not be qt4's fault:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaac12e130 (LWP 3520)]
0x0000003f67808533 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) backtrace
#0  0x0000003f67808533 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x00002aaab0e80c33 in _mesa_unreference_framebuffer (fb=0x970e48) at
main/framebuffer.c:247
#2  0x00002aaab0e1a797 in driDestroyDrawable (drawable=<value optimized out>) at
../common/dri_util.c:520
#3  0x0000003aec021f2d in DestroyContext (dpy=<value optimized out>, gc=<value
optimized out>) at glxcmds.c:102
#4  0x00002aaaaaf74457 in QGLContext::reset (this=0x677f90) at qgl_x11.cpp:624
#5  0x00002aaaaaf55d1e in ~QGLContext (this=0x677f90) at qgl.cpp:1493
#6  0x00002aaaaaf50b3f in ~QGLWidget (this=0x7fff19772050) at qgl.cpp:2538
#7  0x0000000000421859 in Colors::adaptAccordingToEnvironment () at colors.cpp:326
#8  0x000000000042299d in Colors::parseArgs (argc=28, argv=0x7fff197727d8) at
colors.cpp:192
#9  0x000000000040ba87 in main (argc=1, argv=0x7fff197727d8) at main.cpp:54
#10 0x0000003f66c1e2b4 in __libc_start_main () from /lib64/libc.so.6
#11 0x000000000040b989 in _start ()
Comment 6 Craig Schlenter 2008-01-29 00:57:30 EST
The first segfault I see in /var/log/messages is on 16 Jan btw. but I can't
remember when last the demo had actually worked before then :(

I'm pulling down the debuginfo thing slowly to see if my backtrace is
any different (I'm on a 32 bit machine) and will post details in a few
hours...
Comment 7 Craig Schlenter 2008-01-29 06:34:44 EST
Somewhat similar to your backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7fc2720 (LWP 20362)]
0x00e01911 in ?? () from /usr/lib/dri/i915_dri.so
(gdb) backtrace
#0  0x00e01911 in ?? () from /usr/lib/dri/i915_dri.so
#1  0x04fbbe7b in ?? () from /usr/lib/libGL.so.1
#2  0x00476b14 in QGLContext::reset (this=<value optimized out>) at qgl_x11.cpp:624
#3  0x00454f96 in ~QGLContext (this=<value optimized out>) at qgl.cpp:1493
#4  0x0044fd45 in ~QGLWidget (this=<value optimized out>) at qgl.cpp:2538
#5  0x08066b8c in Colors::adaptAccordingToEnvironment () at colors.cpp:326
#6  0x08067e4b in Colors::parseArgs (argc=1, argv=0xbff7c444) at colors.cpp:192
#7  0x08051080 in main (argc=1, argv=Cannot access memory at address 0x4
) at main.cpp:54
#8  0x008444a0 in __libc_start_main () from /lib/libc.so.6
#9  0x08050f71 in _start ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[craig@craigdell ~]$ rpm -qf /usr/lib/dri/i915_dri.so /usr/lib/libGL.so.1
mesa-libGL-7.1-0.8.fc9.i386
mesa-libGL-7.1-0.8.fc9.i386

I'll see if I can downgrade mesa later to see what happens ...
Comment 8 Craig Schlenter 2008-01-29 07:37:03 EST
Hmmm ... downgrading to mesa-libGL-7.1-0.3.fc9.i386.rpm didn't help but using
mesa-libGL-7.0.1-7.fc8.i386.rpm seems to have made the program start again.

I've changed component from "qt" to "mesa" but I'm ignorant of how bugzilla
is supposed to work ... I suppose it should be assigned to ajax?

Thanks!
Comment 9 Craig Schlenter 2008-01-29 07:41:36 EST
ah ... there's a reassign thing at the bottom of the form. I'll click on that
and see what happens...
Comment 10 Rex Dieter 2008-02-21 23:54:05 EST
Tried again today, after a couple of rawhide update iterations, I see something
new (intelInitDriver?)
$ qtdemo-qt4
[intelInitDriver:523] Failed to init TTM buffer manager, falling back to classic.
Segmentation fault
Comment 11 Rex Dieter 2008-02-23 14:18:38 EST
Update to rawthide today and things work happily again, some combination of:
mesa-libGL-7.1-0.16.fc9.x86_64
kernel-2.6.25-0.64.rc2.git5.fc9.x86_64
qt4-4.3.4-1.fc9.x86_64

Note You need to log in before you can comment on or make changes to this bug.