Bug 853587 - Patch for "fix QtScript JIT crash (QTBUG-23871, kde#297661)" applied in qt-4.8.2-5 causes frequent segmentation faults
Summary: Patch for "fix QtScript JIT crash (QTBUG-23871, kde#297661)" applied in qt-4....
Alias: None
Product: Fedora
Classification: Fedora
Component: qt
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH
Depends On:
Blocks: F18Alpha, F18AlphaBlocker F18Alpha-accepted, F18AlphaFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-09-01 01:06 UTC by Sandro Mani
Modified: 2013-10-07 11:00 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-09-07 23:19:04 UTC
Type: Bug

Attachments (Terms of Use)
backtrace (3.03 KB, text/plain)
2012-09-01 01:06 UTC, Sandro Mani
no flags Details
kwin backtrace (5.46 KB, text/plain)
2012-11-17 13:51 UTC, Andrew
no flags Details
plasma-desktop backtrace (14.72 KB, text/plain)
2012-11-17 19:52 UTC, Andrew
no flags Details

System ID Private Priority Status Summary Last Updated
Debian BTS 685524 0 None None None 2012-09-01 02:40:27 UTC
KDE Software Compilation 305718 0 None None None 2012-09-01 02:40:15 UTC
Qt Bug Tracker QTBUG-23871 0 None None None Never
Qt Bug Tracker QTBUG-27322 0 None None None Never

Description Sandro Mani 2012-09-01 01:06:42 UTC
Created attachment 608755 [details]

Description of problem:
After upgrade to qt-4.8.2-5, which applied a patch for QTBUG-23871, frequent segmentation faults are noticeable.

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

How reproducible:

Steps to Reproduce:
1. Start a qt application

Actual results:
Segmentation fault, typical backtrace attached.

Additional info:
See also https://bugs.kde.org/show_bug.cgi?id=305718
Debian removed the patch again: https://bugs.kde.org/show_bug.cgi?id=305718

Seems hardware dependent (seeing here on Core2 Duo T7200, but not on Core2 Duo T9550)

Comment 1 Than Ngo 2012-09-04 14:37:02 UTC
we should revert the patch

Comment 2 Jaroslav Reznik 2012-09-04 15:00:01 UTC
As qt-4.8.2-5.fc17.x86_64 did not hit Fedora updates (only kde-testing) but it's in F18 and we need the fix for Alpha, I changed Version to F18.

(In reply to comment #1)
> we should revert the patch
Already reverted.

Comment 3 Rex Dieter 2012-09-04 15:01:27 UTC
OK, nominating f18alpha blocker, seems there's crashy crashy all over due to this patch.

builds reverting this patch are underway.

Comment 4 Fedora Update System 2012-09-04 16:35:25 UTC
qt-4.8.2-6.fc18 has been submitted as an update for Fedora 18.

Comment 5 Adam Williamson 2012-09-04 19:53:53 UTC
I'm at least +1 NTH, frequent crashes are bad. Probably +1 blocker depending on breadth of impact.

Comment 6 Jaroslav Reznik 2012-09-05 09:03:21 UTC
It's definitely blocker - installed system in KVM is unusable (kwin, plasma crashes), reported by more users. Strange the live is not hit. Also it makes KDE unusable on many common HW configurations.

Fix confirmed, the desktop now starts and does not crash in common tasks.

Comment 7 Martin Bříza 2012-09-05 12:20:30 UTC
I wasn't able to reproduce this behavior in (fully updated, with the appropriate release, of course) Fedora 18 in KVM with any of the methods described on external trackers.
Currently, I'm downloading the packages for Fedora 17 to test if the issue will reveal here.

Comment 8 Kevin Kofler 2012-09-05 12:33:16 UTC
The behavior is very hardware-dependent, it cannot be reproduced by everyone.

Also note that only qt-4.8.2-5 is affected, -4 and -6 are both fine. We did NOT queue -5 to F17 updates-testing or updates. It's only in F18 and Rawhide.

Comment 9 Kevin Kofler 2012-09-05 12:34:02 UTC
(-5 is what is currently in the frozen F18 tree, -6 is what we want to get into it to fix this (in our opinion) blocker.)

Comment 10 Martin Bříza 2012-09-05 12:36:09 UTC
I was asked to reproduce and confirm the origin of the issue, so I'm definitely trying to break it. :) And I'm of course downloading release -5, from the build in koji.

Comment 11 Martin Bříza 2012-09-05 13:55:39 UTC
So, unfortunately, I tried installing the package on bare metal with Fedora 17 and no crashes occur at all.

My Smolt profile: http://www.smolts.org/client/show/pub_29d5b755-c2e0-4bde-a01b-2c5cae1bd6e1

Comment 12 Adam Williamson 2012-09-05 17:29:30 UTC
Discussed at 2012-09-05 blocker review meeting. We weren't quite clear enough on the prevalence of this issue to accept it as blocker, but it is accepted as NTH, so since there's a build with the fix already available, it will go into TC6 and the issue will be fixed.

Comment 13 Jaroslav Reznik 2012-09-06 11:43:46 UTC
Fix confirmed on TC6.

Comment 14 Fedora Update System 2012-09-07 23:19:04 UTC
qt-4.8.2-6.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Andrew 2012-11-11 12:52:30 UTC
Seems like I've caught this with Qt 4.8.3 and KDE 4.9.2 (all from f17 stable repos).
As it is described above KDE was almost unusable because of segfaults.
Fixed with Qt downgrade to 4.8.2 from koji.

More info here: https://bugs.kde.org/show_bug.cgi?id=309889

Comment 16 Rex Dieter 2012-11-11 13:30:40 UTC
which qt build did you see this with?

Subsequent builds (qt-4.8.3-7+) include a better upstream fix

Comment 17 Andrew 2012-11-11 20:50:46 UTC
(In reply to comment #16)
> which qt build did you see this with?

I included more details in KDE bugzilla entry. Tested Qt versions are:
bad: qt-4.8.3-7.fc17.x86_64 (fedora 17 updates repo)
good: qt-4.8.2-7.fc17.x86_64 (taken from koji)

Feel free to ask for any additional testing, it reproduces very well (:

Comment 18 Rex Dieter 2012-11-11 22:11:43 UTC
can you provide a fresh backtrace?

Comment 19 Andrew 2012-11-12 10:33:04 UTC
(In reply to comment #18)
> can you provide a fresh backtrace?

Yes, but what conditions are necessary? I can update qt-4.8.2-7 -> qt-4.8.3-7, but it should be an exactly same setup (and backtrace) as I've put yesterday in KDE #309889. Is it just to be sure that 4.8.3 is really problematic?

Some another point worth mentioning is that I have another machine with different HW but almost same SW and qt-4.8.3-7 works fine there. Not a single crash was observed for that PC.

Comment 20 Andrew 2012-11-17 13:51:41 UTC
Created attachment 646802 [details]
kwin backtrace

Ok, here is a new backtrace after today's update with no packages excluded. Qt was updated to 4.8.3-7 and a lot of KDE packages were updated too. This caused more challenge to revert the transaction because a new KDE packages are dependent on Qt 4.8.3 :)

Note a "virtual memory exhausted: can't allocate ..." error in the trace. Similar errors regarding free memory was thrown from some packages which shouldn't rely on Qt at all (yum, firefox, rpm scriptlets). It was a lot of free RAM (1GB+) around that time, but I'm not sure of peak values.

Comment 21 Kevin Kofler 2012-11-17 17:18:25 UTC
Did you disable memory overcommit in your kernel? If yes, please try again with the default overcommit setting.

Comment 22 Rex Dieter 2012-11-17 17:25:48 UTC
confirmed this backtrace doesn't seem to resemble the one referenced here in the original report.  Best open a new bug please, if you get a chance.

My suspicion is the same as Kevin's, it's some combination of simple memory exhaustion combined with possible non-default/standard kernel/memeory-related settings.

Comment 23 Andrew 2012-11-17 19:52:47 UTC
Created attachment 646939 [details]
plasma-desktop backtrace

(In reply to comment #21)

Yes, I did: vm.overcommit_memory = 2; vm.overcommit_ratio = 100. And you are right, thanks! There are no crashes with value 0 or 1.
It isn't a simplest memory exhausting---there are ~2GB of free RAM + 2GB free swap after KDE startup. So, it should be a new bug opened, as far as I understand. What component is mostly responsible for that?

Besides that, segfault after failed malloc doesn't seem a best case anyway, so it might be two different bugs or even more. Any thoughts are welcome. I put another new backtrace here just in case.

Comment 24 Kevin Kofler 2012-11-17 20:24:16 UTC
It's Qt(WebKit), it's mmapping a huge amount of memory to get the address space it needs for the JIT, it isn't actually using all that memory, but with too strict overcommit settings, the memory is accounted as used and it crashes.

Comment 25 Kevin Kofler 2012-11-17 20:28:19 UTC
Or actually QtScript (in the qt package): The JavaScript stuff is forked from WebKit's JavaScriptCore, but it's qt, not qtwebkit, which is at fault here.

Comment 26 Andrew 2012-11-18 08:56:27 UTC
Ok, thanks! Created #877711

Comment 27 Red Hat Bugzilla 2013-10-04 00:22:15 UTC
Removing external tracker bug with the id '23871' as it is not valid for this tracker

Comment 28 Red Hat Bugzilla 2013-10-04 00:22:21 UTC
Removing external tracker bug with the id '27322' as it is not valid for this tracker

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