| Summary: | Digikam crashed unexpectedly | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Graham Watson <grahamw.home> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 2.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.0.0 | |
| Sentry Crash Report: | |||
|
Description
Graham Watson
2011-06-02 00:26:37 UTC
From your backtrace : Thread 7 (Thread 0x7fafc9454700 (LWP 8278)): [KCrash Handler] #6 0x00007fb0062b7d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #7 0x00007fb0062bbab6 in abort () at abort.c:92 #8 0x00007fb0062b07c5 in __assert_fail (assertion=0x7fafec5ca622 "*_head == _item", file=<value optimized out>, line=701, function=<value optimized out>) at assert.c:81 #9 0x00007fafec5c6629 in avahi_service_browser_free () from /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 #10 0x00007fafba328a38 in net_avahi_callback (c=0x2621e30, state=<value optimized out>, userdata=<value optimized out>) at net.c:854 #11 0x00007fafec5c297e in ?? () from /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 #12 0x00007faffd223ac6 in dbus_connection_dispatch () from /lib/x86_64-linux-gnu/libdbus-1.so.3 #13 0x00007fafec5c9ad6 in ?? () from /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 #14 0x00007fafec7d6620 in avahi_simple_poll_dispatch () from /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 #15 0x00007fafec7d690d in avahi_simple_poll_loop () from /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 #16 0x00007fafec7d698c in ?? () from /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 #17 0x00007fb00606cd8c in start_thread (arg=0x7fafc9454700) at pthread_create.c:304 #18 0x00007fb00636a04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #19 0x0000000000000000 in ?? () ==> internal system problem (libusb, libavahi, etc...) There is no digiKam source code relevant from your backtrace. Gilles Caulier Hi, I don't see how you can say that it isn't a digikam problem - it was clearly the digikam exe that crashed, even if the actual assert is coming from one of the support libraries. Sure it is thread 7 which asserted, but that thread 'belongs' to Digikam. I'm a programmer myself (professional c++). I've not done much programming in Linux, but from the backtrace it looks to me like something (not me) has caused the application to exit, and thread 1 is in the process of exiting digikam and in the middle of calling the ThreadManagerCreator destructor, which is waiting inside a QThreadPool destructor for the threadpool thread to exit. The assert appears to be from an unrelated thread (probably the QThreadPool thread) but I would guess that it is busy with something that digikam is in the middle of destroying or has just destroyed prior to destroying the QThreadPool. Is it possible that you are cleaning up the data that the thread pool is using before stopping the thread pool? Reading it again - libavahi has called abort, which is perhaps the reason for digikam to be shutting down, but perhaps my above hypothesis still stands - it should shut down cleanly in all situations. It does look network related so might be reproducible by the steps I described earlier. Perhaps an interdependency between yanking the network cable whilst the threadpool is at work and it not handling a clean shutdown? Loving Digikam btw, if there's anything I can help with give me a shout :) Regards Graham There is not much difference between calling abort() or doing ((int*)0)++. If libavahi chooses to call abort in the digikam process, it will tear down the process immediately. And it seems quite consistent that a software dealing with network awareness will show activity after and change in network state. So this is an upstream bug in libavahi unless - a backtrace, possibly produced from running under gdb instead of core dump analysis after the crash, suddenly shows the crash occured in digikam code, or - the crash can be reproduced (suspend + resume) with varying backtraces, and or - valgrind shows invalid memory operations by digikam causing memory corruption (probably coninciding with the previous point) At the moment, there is nothing in digikam listening to network state change, so I doubt the hypothesis. |