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.
confirmed (on x86_64). ugh.
it seems one of the qt-copy patches caused the crash in Qt!
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.
I'm installing the gargantuan qt4-debuginfo now, see if we can get a useful trace.
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 ()
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...
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 ...
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!
ah ... there's a reassign thing at the bottom of the form. I'll click on that and see what happens...
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
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