libreport version: 2.0.7 abrt_version: 2.0.6 backtrace_rating: 4 cmdline: /usr/bin/python /usr/bin/openlp comment: Just running the application, after first run wizard crash_function: __GI_raise executable: /usr/bin/python kernel: 3.1.0-7.fc16.x86_64 pid: 13156 pwd: /usr/lib/python2.7/site-packages/openlp/core/utils reason: Process /usr/bin/python was killed by signal 6 (SIGABRT) time: Tue 08 Nov 2011 08:27:13 AM CST uid: 1000 username: rdieter1 backtrace: Text file, 63548 bytes build_ids: Text file, 10332 bytes dso_list: Text file, 25604 bytes environ: Text file, 3754 bytes maps: Text file, 99408 bytes smolt_data: Text file, 2750 bytes var_log_messages: :Nov 7 09:01:57 localhost yum[6552]: Installed: python-gitdb-0.5.4-1.fc16.x86_64 :Nov 7 10:51:47 localhost yum[17874]: Updated: libreport-python-2.0.7-1.fc16.x86_64 :Nov 7 10:51:51 localhost yum[17874]: Updated: abrt-addon-python-2.0.6-1.fc16.x86_64 :Nov 8 07:59:03 localhost yum[30154]: Installed: python-sqlalchemy-0.7.3-1.fc16.x86_64 :Nov 8 07:59:04 localhost yum[30154]: Installed: python-openoffice-0.1-0.8.20090228svn34.fc15.noarch :Nov 8 07:59:05 localhost yum[30154]: Installed: python-lxml-2.3-1.fc16.x86_64 :Nov 8 07:59:06 localhost yum[30154]: Installed: python-setuptools-0.6.24-1.fc16.noarch :Nov 8 07:59:08 localhost yum[30154]: Installed: python-migrate-0.7.1-1.fc16.noarch :Nov 8 08:02:02 localhost abrt[30253]: Saved core dump of pid 30204 (/usr/bin/python) to /var/spool/abrt/ccpp-2011-11-08-08:01:59-30204 (127565824 bytes) :Nov 8 08:24:05 localhost abrt[13007]: Saved core dump of pid 12981 (/usr/bin/python) to /var/spool/abrt/ccpp-2011-11-08-08:24:02-12981 (114286592 bytes) :Nov 8 08:26:18 localhost abrt[13119]: Saved core dump of pid 13101 (/usr/bin/python) to /var/spool/abrt/ccpp-2011-11-08-08:26:16-13101 (114192384 bytes) :Nov 8 08:27:15 localhost abrt[13173]: Saved core dump of pid 13156 (/usr/bin/python) to /var/spool/abrt/ccpp-2011-11-08-08:27:13-13156 (114229248 bytes)
Created attachment 532304 [details] File: maps
Created attachment 532305 [details] File: dso_list
Created attachment 532306 [details] File: environ
Created attachment 532308 [details] File: build_ids
Created attachment 532309 [details] File: smolt_data
Created attachment 532310 [details] File: backtrace
full debugging, backtrace investigating bug #751462 , re-assigning to PyQt4 for now.
*** Bug 751462 has been marked as a duplicate of this bug. ***
Any news on any progress for this bug?
Created attachment 564576 [details] Small Python Program that exhibits the crash I've managed to create a small python program that exhibits this crash. I've found that it doesn't matter what program is executed. My program uses xterm, but any program should cause a crash. This program segfaults on Fedora 16 and openSUSE Factory (12.2). It exits cleanly on openSUSE 12.1 which has older versions of QT$ and py-qt4. I've attached the program to this bug report.
Created attachment 564598 [details] C++ program exhibiting crash It's not python-qt4, it's QT4 itself. I've attached the code that proves it. It's pretty much a C++ version of the python program I posted earlier. It runs fine in openSUSE 12.1 and crashes in openSUSE 12.2 in the exact same way the python example and OpenLP crash. To build it you'll need g++, qmake and the QT4 development packages. Follow these steps to build mkdir qprocess_c++_test cd qprocess_c++_test <Put the file in this directory> qmake -project qmake qprocess_c++_test.pro make
Agreed, seems that something in waitForStarted is running afoul of glibc -D_FORTIFY_SOURCE=2
#0 0x00000036f1e358d5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000036f1e37088 in __GI_abort () at abort.c:91 #2 0x00000036f1e74d0b in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x36f1f76e80 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #3 0x00000036f1f08eb7 in __GI___fortify_fail (msg=msg@entry=0x36f1f76e26 "buffer overflow detected") at fortify_fail.c:32 #4 0x00000036f1f07070 in __GI___chk_fail () at chk_fail.c:29 #5 0x00000036f1f08e67 in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:26 #6 0x00000036fd3504a4 in QProcessPrivate::waitForStarted (this=0x602070, msecs=30000) at io/qprocess_unix.cpp:1024
You cannot waitForStarted() on a process started with startDetached(). startDetached is a static method of QProcess, which starts a process in a fire&forget way, it does not track any state inside a QProcess object (in fact, it can be run without any). Thus, you're running waitForStarted on a default-constructed process where nothing is actually being started in the first place.
(In reply to comment #14) > You cannot waitForStarted() on a process started with startDetached(). > > startDetached is a static method of QProcess, which starts a process in a > fire&forget way, it does not track any state inside a QProcess object (in fact, > it can be run without any). Thus, you're running waitForStarted on a > default-constructed process where nothing is actually being started in the > first place. So it looks like OpenLP has been using this incorrectly. The code didn't cause segfaults in older versions of Fedora, but based on what you said it wasn't doing what the OpenLP developers were expecting it to. Of course this should still throw an exception instead of causing a buffer overflow. Perhaps something changed in glibc or QT4 where this now causes a buffer overflow or it's SELinux or AppArmor (on openSUSE) that's now catching it. Regardless the fact that this causes a buffer overflow is a problem. It should throw an exception. Of course the fix should be done upstream in QT. For what it's worth this issue is also present in openSUSE Factory but not in 12.1 or older. Here's the bug URL https://bugzilla.novell.com/show_bug.cgi?id=748241 OpenLP is tracking the issue on their bugtracker at https://bugs.launchpad.net/bugs/902115