nepomukservicestub crashed with SIGSEGV

[Dennis Schridde]

Binary package hint: kdebase-runtime

Apport claimed nepomukservicestub crashed... Just after login.

ProblemType: Crash
DistroRelease: Ubuntu 10.04
Package: kdebase-runtime 4:4.4.2-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-20.30-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic i686
Architecture: i386
Date: Tue Apr 13 16:08:46 2010
Disassembly: => 0x0: Cannot access memory at address 0x0
ExecutablePath: /usr/bin/nepomukservicestub
InstallationMedia: Kubuntu-Netbook 10.04 "Lucid Lynx" - Beta i386 (20100318)
ProcCmdline: /usr/bin/nepomukservicestub nepomukstorage
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
 LANGUAGE=
SegvAnalysis:
 Segfault happened at: 0x0: Cannot access memory at address 0x0
 PC (0x00000000) not located in a known VMA region (needed executable region)!
SegvReason: executing NULL VMA
Signal: 11
SourcePackage: kdebase-runtime
Stacktrace:
 #0 0x00000000 in ?? ()
 No symbol table info available.
 Cannot access memory at address 0xb49fdfcc
StacktraceTop: ?? ()
Title: nepomukservicestub crashed with SIGSEGV
UserGroups: adm admin cdrom dialout lpadmin netdev plugdev sambashare
XsessionErrors: (process:1743): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Apport retracing service (apport)]

Stacktrace:
 #0 0x00000000 in ?? ()
 No symbol table info available.
 Cannot access memory at address 0xb49fe00c
StacktraceTop: ?? ()

[Apport retracing service (apport)]

Thank you for your report!

However, processing it in order to get sufficient information for the
developers failed (it does not generate an useful symbolic stack trace). This
might be caused by some outdated packages which were installed on your system
at the time of the report:

libudev0: installed version 151-8, latest version: 151-9
udev: installed version 151-8, latest version: 151-9

Please upgrade your system to the latest package versions. If you still
encounter the crash, please file a new report.

Thank you for your understanding, and sorry for the inconvenience!

[Dennis Schridde (devurandom)]

No, I do not understand.
How shall a slightly outdated revision of udev (!) be related to the stacktrace of some nepomuk module missing certain symbols?

[Jonathan Thomas (echidnaman)]

Oh, that's just the bot's excuse that it can't process the crash log.
But there really isn't anything we can do with the crash log, it's too damaged. :(
Is this crash reproducible?

[Dennis Schridde (devurandom)]

Nope, just happens from time to time.

[Dennis Schridde (devurandom)]

P.S: How could it happen that the stack of all threads is so completely corrupted? That seems to be some issue in itself.

[Jonathan Thomas (echidnaman)]

In my experience, about 50% of all Apport-reported nepomuk crashes end up failing to some degree. :(

This does leave us in a tight spot, as Apport is currently the only way to detect nepomukservicestub crashes. The KDE Crash Handler doesn't pick them up, since the service stubs are pure-Qt applications. I think that the best way to proceed from here, if you wish to further invest time in this bug, would be to install kdebase-runtime-dbg (to maximize the chance of things working) and submit a new bug once this happens again.