Summary: | crash starting digikam (after kde 4.3 upgrade) | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Nadav Kavalerchik <nadavkav> |
Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED DOWNSTREAM | ||
Severity: | crash | CC: | andresbajotierra, caulier.gilles, marcel.wiesweg |
Priority: | NOR | ||
Version: | 0.10.0 | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.0.0 | |
Sentry Crash Report: |
Description
Nadav Kavalerchik
2009-08-08 15:27:46 UTC
This could be related to bug 194630 (the functions before the XIOError are the same; and the crash is indeed related to the databse). Thanks FYI, just updated from latest SVN and i still get a crash but it changed a little... Application: digiKam (digikam), signal: Segmentation fault [Current thread is 1 (Thread 0x7fa8fcad8750 (LWP 11804))] Thread 2 (Thread 0x7fa8e9ab6950 (LWP 11805)): [KCrash Handler] #5 0x00007fa8f992dbbe in Digikam::CollectionScanner::setSignalsEnabled (this=0x0, on=true) at /root/sources/graphics/digikam/libs/database/collectionscanner.cpp:139 #6 0x00000000006c4d85 in Digikam::ScanController::connectCollectionScanner (this=0x1b79410, scanner=0x0) at /root/sources/graphics/digikam/digikam/scancontroller.cpp:449 #7 0x00007fa8f999a57d in Digikam::SchemaUpdater::update (this=0x7fa8e9ab5f00) at /root/sources/graphics/digikam/libs/database/schemaupdater.cpp:97 #8 0x00007fa8f994bef1 in Digikam::DatabaseBackend::initSchema (this=0x1b86c00, updater=0x7fa8e9ab5f00) at /root/sources/graphics/digikam/libs/database/databasebackend.cpp:72 #9 0x00007fa8f994646c in Digikam::DatabaseAccess::checkReadyForUse (observer=0x1b79420) at /root/sources/graphics/digikam/libs/database/databaseaccess.cpp:246 #10 0x00000000006c6ca7 in Digikam::ScanController::run (this=0x1b79410) at /root/sources/graphics/digikam/digikam/scancontroller.cpp:420 #11 0x00007fa8f7a1f3f5 in QThreadPrivate::start (arg=0x1b79410) at thread/qthread_unix.cpp:188 #12 0x00007fa8f4bbbf9a in start_thread (arg=<value optimized out>) at pthread_create.c:300 #13 0x00007fa8f5e0e56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #14 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fa8fcad8750 (LWP 11804)): #0 0x00007fa8f5e05d36 in *__GI___poll (fds=0x7ffffe2ac340, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fa8efe6990a in ?? () from /usr/lib/libxcb.so.1 #2 0x00007fa8efe69ed9 in ?? () from /usr/lib/libxcb.so.1 #3 0x00007fa8efe6a185 in xcb_writev () from /usr/lib/libxcb.so.1 #4 0x00007fa8f51cd3d6 in _XSend () from /usr/lib/libX11.so.6 #5 0x00007fa8f51cd975 in _XFlush () from /usr/lib/libX11.so.6 #6 0x00007fa8f51a3ae8 in XDrawLine () from /usr/lib/libX11.so.6 #7 0x00007fa8f6bcd200 in QX11PaintEngine::drawLines (this=<value optimized out>, lines=<value optimized out>, lineCount=1) at painting/qpaintengine_x11.cpp:699 #8 0x00007fa8f6b34d86 in QPainter::drawLines (this=<value optimized out>, lines=0x7ffffe2ac700, lineCount=1) at painting/qpainter.cpp:4639 #9 0x00007fa8edb853c3 in ?? () from /usr/lib/kde4/plugins/styles/libpolyester.so #10 0x00007fa8edb97228 in ?? () from /usr/lib/kde4/plugins/styles/libpolyester.so #11 0x00007fa8f6cd2e97 in QCommonStyle::drawControl (this=0x1a32e20, element=<value optimized out>, opt=0x7ffffe2b02a0, p=0x7ffffe2b0300, widget=0x1b91f60) at styles/qcommonstyle.cpp:1483 #12 0x00007fa8f897dca4 in KStyle::drawControl (this=0x1a32e20, element=QStyle::CE_ProgressBar, option=0x7ffffe2b02a0, p=0x7ffffe2b0300, widget=0x1b91f60) at ../../kdeui/kernel/kstyle.cpp:2502 #13 0x00007fa8edb93358 in ?? () from /usr/lib/kde4/plugins/styles/libpolyester.so #14 0x00007fa8f6e1ed63 in QStylePainter::drawControl (this=0x1b91f60) at ../../include/QtGui/../../src/gui/painting/qstylepainter.h:89 #15 QProgressBar::paintEvent (this=0x1b91f60) at widgets/qprogressbar.cpp:395 #16 0x00007fa8f6a65906 in QWidget::event (this=0x1b91f60, event=0x7ffffe2b0a20) at kernel/qwidget.cpp:7687 #17 0x00007fa8f6e1e77c in QProgressBar::event (this=0x1b91f60, e=0x7ffffe2b0a20) at widgets/qprogressbar.cpp:561 #18 0x00007fa8f6a157ad in QApplicationPrivate::notify_helper (this=0x19911a0, receiver=0x1b91f60, e=0x7ffffe2b0a20) at kernel/qapplication.cpp:4056 #19 0x00007fa8f6a1d80a in QApplication::notify (this=0x7ffffe2b3a60, receiver=0x1b91f60, e=0x7ffffe2b0a20) at kernel/qapplication.cpp:4021 #20 0x00007fa8f896eb2b in KApplication::notify (this=0x7ffffe2b3a60, receiver=0x1b91f60, event=0x7ffffe2b0a20) at ../../kdeui/kernel/kapplication.cpp:302 #21 0x00007fa8f7b0549c in QCoreApplication::notifyInternal (this=0x7ffffe2b3a60, receiver=0x1b91f60, event=0x7ffffe2b0a20) at kernel/qcoreapplication.cpp:610 #22 0x00007fa8f6a6c92e in QWidgetPrivate::drawWidget (this=0x1b751d0, pdev=0x1b2bfe8, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x1b3fef0) at kernel/qwidget.cpp:5079 #23 0x00007fa8f6a6d077 in QWidgetPrivate::paintSiblingsRecursive (this=0x1b7b8a0, pdev=0x1b2bfe8, siblings=..., index=5, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x1b3fef0) at kernel/qwidget.cpp:5189 #24 0x00007fa8f6a6c5a7 in QWidgetPrivate::drawWidget (this=0x1b7b8a0, pdev=0x1b2bfe8, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x1b3fef0) at kernel/qwidget.cpp:5128 #25 0x00007fa8f6a6d077 in QWidgetPrivate::paintSiblingsRecursive (this=0x1ac2110, pdev=0x1b2bfe8, siblings=..., index=1, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x1b3fef0) at kernel/qwidget.cpp:5189 #26 0x00007fa8f6a6c5a7 in QWidgetPrivate::drawWidget (this=0x1ac2110, pdev=0x1b2bfe8, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x1b3fef0) at kernel/qwidget.cpp:5128 #27 0x00007fa8f6be3345 in QWidgetBackingStore::sync (this=0x1b3fef0) at painting/qbackingstore.cpp:1269 #28 0x00007fa8f6be363a in QWidgetBackingStore::sync (this=0x1b3fef0, exposedWidget=0x1b855c0, exposedRegion=...) at painting/qbackingstore.cpp:1074 #29 0x00007fa8f6a74622 in QETWidget::translatePaintEvent (this=0x1b855c0, event=<value optimized out>) at kernel/qapplication_x11.cpp:5109 #30 0x00007fa8f6a84e8d in QApplication::x11ProcessEvent (this=0x7ffffe2b3a60, event=0x7ffffe2b3010) at kernel/qapplication_x11.cpp:3450 #31 0x00007fa8f6aace3c in x11EventSourceDispatch (s=0x1994fa0, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #32 0x00007fa8f0de410a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #33 0x00007fa8f0de7968 in ?? () from /usr/lib/libglib-2.0.so.0 #34 0x00007fa8f0de7b1c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #35 0x00007fa8f7b2db7f in QEventDispatcherGlib::processEvents (this=0x1960ba0, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327 #36 0x00007fa8f6aac5ef in QGuiEventDispatcherGlib::processEvents (this=0x7ffffe2ac340, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #37 0x00007fa8f7b03d62 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149 #38 0x00007fa8f7b04134 in QEventLoop::exec (this=0x1b88a30, flags=...) at kernel/qeventloop.cpp:201 #39 0x00000000006c5630 in Digikam::ScanController::databaseInitialization (this=0x1b79410) at /root/sources/graphics/digikam/digikam/scancontroller.cpp:308 #40 0x000000000062556a in Digikam::AlbumManager::setDatabase (this=0x1aef9e0, dbPath=..., priority=false) at /root/sources/graphics/digikam/digikam/albummanager.cpp:506 #41 0x00000000006f11c7 in main (argc=1, argv=0x7ffffe2b4088) at /root/sources/graphics/digikam/digikam/main.cpp:158 There was a similar backtrace some time ago, cant remember the bug. I suspect some binary compatibility problem. You said you compiled from current SVN, but if you compare the line numbers of scancontroller.cpp in the backtrace with that file from current trunk: http://websvn.kde.org/*checkout*/trunk/extragear/graphics/digikam/digikam/scancontroller.cpp?revision=1006827&content-type=text/plain you will see that the line numbers from the backtrace dont point to any related code. Even more, the method connectCollectionScanner is never called from the given call context. Note that scancontroller.cpp is linked in the main digikam binary while databaseaccess.cpp and schemaupdater.cpp are linked in libdigikamdatabase.so. indeed :-) but, i follow the instructions on this page : http://www.digikam.org/drupal/download/svn?q=download/KDE4 and i get a different svn revision id: laptop:~/sources/graphics# svn up At revision 1009242. maybe i got lost inside the svn tree ? (it used to work until a few days ago) And ~ is /root/ ? You can run LD_LIBRARY_PATH=~/sources/graphics/lib:${LD_LIBRARY_PATH} ~/sources/graphics/digikam/digikam/digikam to assert you are running the binary from your SVN directory. If you start digikam under gdb, is the backtrace the same? yes. ~ is /root/ :-) and you are right too. your library trick worked :-) just saw your Batch Queue Manager for the first time in action... my heart missed a bit ! what an awesome and beautiful tool :-) it is what i was waiting for 4 a long time. save so much work and keep my batch actions consistent !!! now i use: export LD_LIBRARY_PATH=~/sources/graphics/lib:${LD_LIBRARY_PATH} && /root/sources/graphics/build/digikam/digikam/digikam to start digikam with a "one-liner" i guess the libs are not copied to (or over) the system's libs do you suggest i configure it to be installed in /usr/local... ? ( i do not have debian's pre-compiled version installed on the system ) I am no expert on KDE installation issues. I just specify no installation prefix and let CMake detect everything for me, so that the libs always go to one place and this place is known to kdelibs. Everything else may involve adjusting KDEDIRS or LD_LIBRARY_PATH and I can live without doing that. me too. it used to work fine until that last upgrade. (kde42 >> kde43) i might copy those files manually. thou, i use your trick for now. thanks :-) |