Description of problem: Plasma crashed after logon. No panel/desktop showed, just crash from plasma. After moment starting sound is played and then everything work normally (except plasma). When i ran it from konsole - same behaviour. Emptying ~/.kde has no effect. Version-Release number of selected component (if applicable): kdebase-workspace-4.4.85-3.fc14.i686 How reproducible: always Additional info: Fresh F14 installation and then yum install @kde. Backtrace is in the KDE bugzilla.
This is a crash in Qt's JavaScript JIT. I think we need to disable it again.
rpm -q qt please why can't we ever reproduce this reliably?
Or maybe it's i686-specific (most of our devs use x86_64 it seems, me included)
Qt version is qt-4.7.0-0.16.beta1.fc14.i686
It looks like that JavaScript JIT is the problem. I downgraded to qt-4.7.0-0.13.beta1.fc14.i686 (last version with -no-javascript-jit) and now plasma works.
OK. :( How should we move forward, blacklist known-bad platforms or whitelist known-good ones? (I'm of a mind to use the blacklist strategy).
can you post the output of: cat /proc/cpuinfo
I'm running it in the virtual machine (VirtualBox). processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5110 @ 1.60GHz stepping : 6 cpu MHz : 1675.655 cache size : 0 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 constant_tsc up pni monitor bogomips : 3351.31 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Can this be reproduced on actual hardware? If not, it needs to be fixed in VirtualBox, not worked around in Qt.
oh boo. I think I would have to agree with Kevin here. we really need this reproducible on bare-metal (or at least pure fedora bits, say using kvm) to justify losing the performance advantages brought but the javascript-jit.
Do you have selinux enabled? If this is the case (selinux enabled and logged execmem execution), then there's no difference between bare-metal and VirtualBox.
fwiw, when we first enabled this, we had several independant confirmations that things did work ok, including a i686 kvm-based VM I used. go figure.
This is weird. I downgraded qt to -13, upgraded it -18 (works fine) and downgraded again to -16 and now the crash is gone. I don't what happened - I did an yum update meantime, so something might fix that.
ok, wierd. let's consider this a passing gremlin, and I'll revert the change. Please re-open if problems resurface.
Created attachment 430252 [details] Backtrace QT
qt-4.7.0-0.24.beta1.fc14.x86_64 I'm not in a VM.
Okay i think it's an issue with SELinux, setenforce 0 allow plasma-desktop to start. ---- time->Thu Jul 8 03:12:39 2010 type=SYSCALL msg=audit(1278573159.198:25059): arch=c000003e syscall=9 success=yes exit=140057755234304 a0=0 a1=4000 a2=7 a3=22 items=0 ppid=13603 pid=13606 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="plasma-desktop" exe="/usr/bin/plasma-desktop" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1278573159.198:25059): avc: denied { execmem } for pid=13606 comm="plasma-desktop" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process Allow access by executing: # setsebool -P allow_execmem 1 type=AVC msg=audit(1278573159.198:25059): avc: denied { execmem } for pid=13606 comm="plasma-desktop" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process Was caused by: One of the following booleans was set incorrectly. Description: Allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla") Allow access by executing: # setsebool -P allow_execstack 1 Description: Allow unconfined executables to map a memory region as both executable and writable, this is dangerous and the executable should be reported in bugzilla") Allow access by executing: # setsebool -P allow_execmem 1
Rex, could you look at the backtrace, i'm not sure if it's the same bug or not.
What applets are active on your plasma-desktop?
(In reply to comment #19) > What applets are active on your plasma-desktop? Only Folder View. I did not forced a relabel of the HDDs from F13 to Rawhide so that might explain the SELinux AVC denial. I should try to reproduce it in a VM.
Created attachment 430492 [details] backtrace of plasma-desktop
It's definitely SELinux issue. I reproduced it on new VirtualBox installation, then I ran "setenforce 0" and it didn't crashed. But no crash after "setenforce 1" and after reboot.
Frankly, I don't care much about this on VirtuslBox (since it may be virtualbox-specific), at the moment. I care more about bare-metal, and possibly even kvm/qemu.
(In reply to comment #23) > Frankly, I don't care much about this on VirtuslBox (since it may be > virtualbox-specific), at the moment. > > I care more about bare-metal, and possibly even kvm/qemu. Rex, i reproduced it twice and it seems to be related to SELinux. 1st time = updated from F13 to Rawhide and 2nd time it was inside a VM (KVM).
And yet my f13/i386 kvm vm was fine. Maybe this is specific to rawhide selinux policy?
(In reply to comment #25) > And yet my f13/i386 kvm vm was fine. > > Maybe this is specific to rawhide selinux policy? Okay, i will CC Daniel Walsh, maybe he can give us some advices?
Does chcon -t execmem_exec_t /usr/bin/plasma-desktop Fix the problem?
$ ls -Z /usr/bin/plasma-desktop -rwxr-xr-x. root root system_u:object_r:execmem_exec_t:s0 /usr/bin/plasma-desktop
Is that a yes?
(In reply to comment #29) > Is that a yes? Woops sorry Daniel, the file is already labeled execmem_exec_t:s0
(In reply to comment #22) > It's definitely SELinux issue. I reproduced it on new VirtualBox installation, > then I ran "setenforce 0" and it didn't crashed. But no crash after "setenforce > 1" and after reboot. Could you verify the label on plasma-desktop please, as a confirmation. I had the same experience, setting setenforce to 0 allowed plasma-desktop to start (for the 1st login), from that point it was fine.
Unfortunately, setting execmem on plasma-desktop would not be a real fix even if it solves the problem, there's much more stuff using the QtWebKit JavaScript engine than just Plasma. Any app using QtWebKit (with any JavaScript) or QtScript (which now also uses this JavaScript engine) will use this engine. If the JIT still requires execmem, we will have to disable it again. The strange thing is that some people apparently have this working with SELinux enabled, others don't.
Well you can turn the check off altogether by turning on the allow_execmem boolean as described above. setsebool -P allow_execmem 1
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Carl, if you're still seeing this mind giving output of rpm -q qt fedora-release and cat /proc/cpuinfo
ok, meh, on my f13/x86_64 box I seem to have allow_execmem --> on what is the f13 and f14 default wrt to allow_execmem? (I don't recall ever changing it).
ok, confirmed using f13 live image; allow_execmem --> on is f13 default it seems. So, this is changing with f14? We will indeed be forced to disable the jit or find some other workaround.
FWIW, the JIT has always been disabled so far. We enabled it with Qt 4.7 because we thought the execmem issues had been resolved upstream given that we couldn't reproduce them. It turns out this is just because F13 allows execmem by default. :-( So disabling the JIT would just be restoring existing behavior of all released Fedoras.
And FYI, webkitgtk, which uses the same JIT, is still being built with --disable-jit and has been built that way for almost as long as the JIT exists in the first place. I think we really need to build Qt with -no-javascript-jit and stop trying to enable it at every single Qt release, each time getting a new bug filed with AVCs and a new discussion. If upstream resolves https://bugs.webkit.org/show_bug.cgi?id=35154 we can reenable it. But so far that bug is being ignored entirely. So -no-javascript-jit is the only sensible option.
(In reply to comment #39) > And FYI, webkitgtk, which uses the same JIT, is still being built with > --disable-jit and has been built that way for almost as long as the JIT exists > in the first place. > > I think we really need to build Qt with -no-javascript-jit and stop trying to > enable it at every single Qt release, each time getting a new bug filed with > AVCs and a new discussion. If upstream resolves > https://bugs.webkit.org/show_bug.cgi?id=35154 we can reenable it. But so far > that bug is being ignored entirely. So -no-javascript-jit is the only sensible > option. Agreed.
Any update on this bug report? Since F14 have allow_execmem => on.
We build Qt with the JavaScript JIT enabled now.
Why is this still open? We decided to close this, given that allow_execmem is on by default.
*** Bug 693141 has been marked as a duplicate of this bug. ***
*** Bug 654173 has been marked as a duplicate of this bug. ***