Summary: | nepomuk segfault without any obvious trigger | ||
---|---|---|---|
Product: | nepomuk | Reporter: | Scott Wood <scott> |
Component: | general | Assignee: | Sebastian Trueg <sebastian> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | maninred, me, trueg |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Scott Wood
2011-09-04 03:08:38 UTC
Could you run the strigi indexer in valgrind and reproduce this one? For that you have to disable the indexer in the nepomuk config: "kcmshell4 nepomuk". Then start it manually in valgrind: valgrind nepomukservicestub nepomukstrigiservice Hopefully it will tell me more. (In reply to comment #1) > Could you run the strigi indexer in valgrind and reproduce this one? > For that you have to disable the indexer in the nepomuk config: "kcmshell4 > nepomuk". Then start it manually in valgrind: It was already unchecked -- not sure if it was always that way, or is there something that would have it off when it crashed? Is there any other way the Strigi stuff could have showed up in the backtrace? > valgrind nepomukservicestub nepomukstrigiservice > > Hopefully it will tell me more. I got this so far, probably not related: ==30305== Conditional jump or move depends on uninitialised value(s) ==30305== at 0x7884510: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==30305== by 0x7884605: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4) ==30305== by 0xB0511C0: png_create_read_struct_2 (in /lib/x86_64-linux-gnu/libpng12.so.0.44.0) ==30305== by 0xB051366: png_create_read_struct (in /lib/x86_64-linux-gnu/libpng12.so.0.44.0) ==30305== by 0x65D5BE6: QPngHandlerPrivate::readPngHeader() (qpnghandler.cpp:368) ==30305== by 0x65D6914: QPngHandlerPrivate::readPngImage(QImage*) (qpnghandler.cpp:439) ==30305== by 0x65A6C57: QImageReader::read(QImage*) (qimagereader.cpp:1205) ==30305== by 0x65A72A6: QImageReader::read() (qimagereader.cpp:1155) ==30305== by 0x659C4F1: operator>>(QDataStream&, QImage&) (qimage.cpp:5204) ==30305== by 0x65B6DE5: operator>>(QDataStream&, QPixmap&) (qpixmap.cpp:1329) ==30305== by 0x5BD80AE: KIconLoaderPrivate::findCachedPixmapWithPath(QString const&, QPixmap&, QString&) (kiconloader.cpp:876) ==30305== by 0x5BDC7C8: KIconLoader::loadIcon(QString const&, KIconLoader::Group, int, int, QStringList const&, QString*, bool) const (kiconloader.cpp:1222) ==30305== Error in parsing: Keyword obj not found. (In reply to comment #2) > > valgrind nepomukservicestub nepomukstrigiservice > > > > Hopefully it will tell me more. > > I got this so far, probably not related: > ==30305== Conditional jump or move depends on uninitialised value(s) > ==30305== at 0x7884510: inflateReset2 (in > /lib/x86_64-linux-gnu/libz.so.1.2.3.4) > ==30305== by 0x7884605: inflateInit2_ (in > /lib/x86_64-linux-gnu/libz.so.1.2.3.4) > ==30305== by 0xB0511C0: png_create_read_struct_2 (in > /lib/x86_64-linux-gnu/libpng12.so.0.44.0) > ==30305== by 0xB051366: png_create_read_struct (in > /lib/x86_64-linux-gnu/libpng12.so.0.44.0) > ==30305== by 0x65D5BE6: QPngHandlerPrivate::readPngHeader() > (qpnghandler.cpp:368) > ==30305== by 0x65D6914: QPngHandlerPrivate::readPngImage(QImage*) > (qpnghandler.cpp:439) > ==30305== by 0x65A6C57: QImageReader::read(QImage*) (qimagereader.cpp:1205) > ==30305== by 0x65A72A6: QImageReader::read() (qimagereader.cpp:1155) > ==30305== by 0x659C4F1: operator>>(QDataStream&, QImage&) (qimage.cpp:5204) > ==30305== by 0x65B6DE5: operator>>(QDataStream&, QPixmap&) > (qpixmap.cpp:1329) > ==30305== by 0x5BD80AE: KIconLoaderPrivate::findCachedPixmapWithPath(QString > const&, QPixmap&, QString&) (kiconloader.cpp:876) > ==30305== by 0x5BDC7C8: KIconLoader::loadIcon(QString const&, > KIconLoader::Group, int, int, QStringList const&, QString*, bool) const > (kiconloader.cpp:1222) > ==30305== > Error in parsing: Keyword obj not found. Did it actually crash? (In reply to comment #3) > Did it actually crash? No, I haven't been able to reproduce the crash. *** Bug 276359 has been marked as a duplicate of this bug. *** (In reply to comment #4) > (In reply to comment #3) > > Did it actually crash? > > No, I haven't been able to reproduce the crash. Are you running KDE 4.7.1 in the meantime? If so this bug can be closed as fixed since the crashing code has been protected with mutexes. (In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > Did it actually crash? > > > > No, I haven't been able to reproduce the crash. > > Are you running KDE 4.7.1 in the meantime? If so this bug can be closed as > fixed since the crashing code has been protected with mutexes. I'm running the version 4:4.7.0a-0ubuntu1~natty1~ppa1 of the Ubuntu kde-runtime package. If it's been fixed since then, I apologize for the noise. I don't see "mutex" anywhere in the patches Ubuntu has applied, so I assume this fix hasn't been backported. Closing this as a duplicate of bug 275880 since I am fairly certain that it can be the only source of the problem. Hopefully the patch I posted there does also solve this crash. *** This bug has been marked as a duplicate of bug 275880 *** |