|
https://bugs.kde.org/show_bug.cgi?id=303186
Bug ID: 303186 Severity: crash Version: 2.6.0 Priority: NOR Assignee: [hidden email] Summary: crash on Shortcut edit for tagging Classification: Unclassified OS: Linux Reporter: [hidden email] Hardware: Debian unstable Status: UNCONFIRMED Component: general Product: digikam Application: digikam (2.6.0) KDE Platform Version: 4.8.4 (4.8.4) Qt Version: 4.8.2 Operating System: Linux 3.2.0-2-686-pae i686 Distribution: Debian GNU/Linux unstable (sid) -- Information about the crash: - What I was doing when the application crashed: Settings >> Configure shortcuts >> Select "Assign Tag "xxx"" >> Click on "Custom" radio button >> crash - Custom settings of the application: CTRL-B is assigned to a tag. I have noticed something which weren't there before upgrade: now tagging images using the shortcut generates a few working threads: - assignment of a tag - working normally - flushing metadata - it's okay as well - removal of a tag - never starts, never finishes, and I cannot see what it wants to remove. these are accumulating, until I exit. I think using the shortcut for removal is the same in reverse: there is an assignment of a tag thread starts, lingering on forever. This is Debian/sid, using latest libs which the package depends on, but not all of KDE is refreshed. (It's a multi-gigabyte refresh, still pending...) The crash can be reproduced every time. -- Backtrace: Application: digiKam (digikam), signal: Segmentation fault Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". [Current thread is 1 (Thread 0xae8368c0 (LWP 29066))] Thread 4 (Thread 0xac788b70 (LWP 29075)): #0 0xb7780424 in __kernel_vsyscall () #1 0xb348f20a in __pthread_cond_wait (cond=0x895ea80, mutex=0x895ea68) at pthread_cond_wait.c:153 #2 0xb472f36d in __pthread_cond_wait (cond=0x895ea80, mutex=0x895ea68) at forward.c:139 #3 0xb49ce460 in wait (time=4294967295, this=0x895ea68) at thread/qwaitcondition_unix.cpp:86 #4 QWaitCondition::wait (this=0x895e9d4, mutex=0x895e9d0, time=4294967295) at thread/qwaitcondition_unix.cpp:158 #5 0x081fc1a7 in Digikam::ScanController::run() () #6 0xb49cdef0 in QThreadPrivate::start (arg=0x8948710) at thread/qthread_unix.cpp:307 #7 0xb348ac39 in start_thread (arg=0xac788b70) at pthread_create.c:304 #8 0xb472227e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 3 (Thread 0xabf87b70 (LWP 29076)): #0 0xb7780424 in __kernel_vsyscall () #1 0xb4714886 in *__GI___poll (fds=0xb47aaff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0xb308e6ab in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb3080c3e in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb3080d91 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb4b1191f in QEventDispatcherGlib::processEvents (this=0xab600468, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #6 0xb4ade0dc in QEventLoop::processEvents (this=this@entry=0xabf870f8, flags=...) at kernel/qeventloop.cpp:149 #7 0xb4ade3d1 in QEventLoop::exec (this=0xabf870f8, flags=...) at kernel/qeventloop.cpp:204 #8 0xb49cab2c in QThread::exec (this=0x8961a48) at thread/qthread.cpp:501 #9 0xb4abc7dd in QInotifyFileSystemWatcherEngine::run (this=0x8961a48) at io/qfilesystemwatcher_inotify.cpp:248 #10 0xb49cdef0 in QThreadPrivate::start (arg=0x8961a48) at thread/qthread_unix.cpp:307 #11 0xb348ac39 in start_thread (arg=0xabf87b70) at pthread_create.c:304 #12 0xb472227e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 2 (Thread 0xab5ffb70 (LWP 29078)): #0 0xb7780424 in __kernel_vsyscall () #1 0xb348f20a in __pthread_cond_wait (cond=0x8b3b7a8, mutex=0x8b3b790) at pthread_cond_wait.c:153 #2 0xb472f36d in __pthread_cond_wait (cond=0x8b3b7a8, mutex=0x8b3b790) at forward.c:139 #3 0xb49ce460 in wait (time=4294967295, this=0x8b3b790) at thread/qwaitcondition_unix.cpp:86 #4 QWaitCondition::wait (this=0x89e6a58, mutex=0x89e6a54, time=4294967295) at thread/qwaitcondition_unix.cpp:158 #5 0xb6a1c6ce in Digikam::ParkingThread::run() () from /usr/lib/libdigikamcore.so.2 #6 0xb49cdef0 in QThreadPrivate::start (arg=0x89e6a48) at thread/qthread_unix.cpp:307 #7 0xb348ac39 in start_thread (arg=0xab5ffb70) at pthread_create.c:304 #8 0xb472227e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 1 (Thread 0xae8368c0 (LWP 29066)): [KCrash Handler] #7 0xb509db86 in QKeySequence::isEmpty (this=0xaabe588) at kernel/qkeysequence.cpp:1064 #8 0xb506f462 in QAction::shortcuts (this=0xaa88ad8) at kernel/qaction.cpp:508 #9 0xb5b1899f in KAction::shortcut (this=0xaa88ad8, type=...) at ../../kdeui/actions/kaction.cpp:193 #10 0xbf929a2c in ?? () #11 0xb5e5dff4 in ?? () from /usr/lib/libkdeui.so.5 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Reported using DrKonqi -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
https://bugs.kde.org/show_bug.cgi?id=303186
Gilles Caulier <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] Component|general |shortcuts Version|2.6.0 |unspecified Assignee|[hidden email] |[hidden email] Product|digikam |kdelibs --- Comment #1 from Gilles Caulier <[hidden email]> --- Sound like it crash in KDELibs, not digiKam... Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
