Bug 853587

we should revert the patch

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.

OK, nominating f18alpha blocker, seems there's crashy crashy all over due to this patch.

builds reverting this patch are underway.

qt-4.8.2-6.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qt-4.8.2-6.fc18

I'm at least +1 NTH, frequent crashes are bad. Probably +1 blocker depending on breadth of impact.

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.

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.

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.

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

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.

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

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.

Fix confirmed on TC6.

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.

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

which qt build did you see this with?

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

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

can you provide a fresh backtrace?

(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.

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.

Did you disable memory overcommit in your kernel? If yes, please try again with the default overcommit setting.

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.

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.

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.

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.

Ok, thanks! Created #877711

Removing external tracker bug with the id '23871' as it is not valid for this tracker

Removing external tracker bug with the id '27322' as it is not valid for this tracker