Bug 1274904

Created attachment 1085904 [details]
File: backtrace

Created attachment 1085906 [details]
File: cgroup

Created attachment 1085907 [details]
File: core_backtrace

Created attachment 1085908 [details]
File: dso_list

Created attachment 1085909 [details]
File: environ

Created attachment 1085910 [details]
File: limits

Created attachment 1085911 [details]
File: maps

Created attachment 1085912 [details]
File: mountinfo

Created attachment 1085913 [details]
File: open_fds

Created attachment 1085914 [details]
File: proc_pid_status

If you were running the 'launch all applications' test, note it's best to do that after install, not when running live; live sessions are kinda intrinsically subject to running out of RAM at some point, at which point all kinds of weird stuff starts happening.

If you just booted live then ran gnome-abrt, that could be problematic indeed. I'll see if I can reproduce.

Hrm... baloo service shouldn't even be running on live...

I forgot to mention that I'm testing with qemu-kvm.

(In reply to awilliam from comment #11)
> If you just booted live then ran gnome-abrt, that could be problematic
> indeed. I'll see if I can reproduce.

I've just launched gnome-abrt right after the boot. The issue seems reproducible only in a live environment: I haven't hit on the installed system yet.

Another user experienced a similar problem:

Booted F23 Final RC3 KDE i686 live, waited a bit, ran Konqueror from the kicker. The shell crashed then respawned itself, and this notification appeared.

reporter:       libreport-2.6.2
backtrace_rating: 4
cmdline:        /bin/plasmashell --shut-up
crash_function: KCrash::defaultCrashHandler
executable:     /usr/bin/plasmashell
global_pid:     1657
kernel:         4.2.3-300.fc23.i686
package:        plasma-workspace-5.4.2-4.fc23
reason:         plasmashell killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Hmm, so yeah, I hit the same crash, only running a different app.

`ps aux | grep aloo` on the live image shows `/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer` running.

I actually think just opening the Kicker is enough to trigger this one, it happened to me again. Well, I think it was the same thing, this time the shell never came back so I was just stuck with a console. I'm gonna attach ~/.xsession-errors from that crash.

Created attachment 1085972 [details]
.xsession-errors from a reproduction

I'm proposing this as a blocker. It seems fairly trivially reproducible: just boot a 32-bit KDE live image, open the Kicker, and type a couple of characters. Seems to cause the crash every time.

There's a criteria problem here because all our desktop functionality requirements are technically for *post-install*, but I'll cite:

"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."

and say that I reckon at least some of the desktop functionality requirements should apply to the live environment as well as the installed environment.

+1 blocker.
(We are still blocking on i686 for f23 right?)

Yup.

I have a suspicion this *may* be fixed with lmdb-0.9.16-1.fc23,
http://koji.fedoraproject.org/koji/buildinfo?buildID=677308

which was built, but never submitted as an update.

I'll try testing myself with a i686/32bit setup at first opportunity, but I'd encourage anyone else to try lmdb-0.9.16-1.fc23 to see if that helps.

lmdb-0.9.16-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-25d6622b7d

Discussed at 2015-10-26 blocker review meeting: [1]. 

This bug was accepted as Final blocker: This bug is a clear violation of the following criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2015-10-26/f23-blocker-review.2015-10-26-16.00.html

The lmdb update does appear to fix this in at least one test, yep. I'm running into another issue in testing, will double-confirm later.

Yeah, the fix works.

lmdb-0.9.16-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update lmdb'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-25d6622b7d

Oh, damn - yes, I see this in RC5 too.

I think I may have tested this wrong before: I somehow got mixed up and thought the crash happened on *installed* systems, when in fact it happens running live. So I tested after install and didn't see the crash :( My bad.

FWIW, I built an image with the kickstart bit that disables the Baloo indexer commented out, and that makes the bug go away. The bug doesn't happen post-install (another case where the indexer would run), and it doesn't happen on x86_64. So, it looks like the bug happens only on 32-bit, and only when the Baloo indexer didn't run (so presumably some database or other that it goes to look in is empty or not there or similar).

kf5-baloo-5.14.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-3093b24027

That one really *does* seem to fix the bug. I'm like nearly certain I tested it right this time! :)

I also confirmed the issue is still fixed if I drop lmdb back to 0.9.14-2 - we really only need the baloo patch to fix this, not the updated lmdb.

Looks like it's fixed in RC6 with kf5-baloo-5.14.0-3.fc23.

*** Bug 1276495 has been marked as a duplicate of this bug. ***

kf5-baloo-5.14.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.