Bug 168846 - crash after playing with tags (seems to be rather a crash in Qt or kdelibs)
Summary: crash after playing with tags (seems to be rather a crash in Qt or kdelibs)
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Engine (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-10 14:48 UTC by Oliver Putz
Modified: 2022-01-22 14:02 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Putz 2008-08-10 14:48:31 UTC
Version:           0.10.0-beta1 (using 4.1.00 (KDE 4.1.0), Gentoo)
Compiler:          i686-pc-linux-gnu-gcc
OS:                Linux (i686) release 2.6.25-gentoo-r7

I opened digikam, created a new tag, tagged some images with that tag, deleted some tags from some of the images and finally closed digikam. When I closed it, it crashed with the backtrace below. So far I have not been able to reproduce this crash. Also: Digikam does not really seem to be the culprit anyway... Looks to me more like a problem in kdelibs or Qt?

Application: digiKam (digikam), signal SIGABRT
[Thread debugging using libthread_db enabled]
[New Thread 0xb4e3b720 (LWP 582)]
[New Thread 0xad8fcb90 (LWP 637)]
[New Thread 0xb30fbb90 (LWP 617)]
[New Thread 0xb28fab90 (LWP 616)]
[KCrash handler]
#6  0xffffe424 in __kernel_vsyscall ()
#7  0xb5534690 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#8  0xb5535ed8 in *__GI_abort () at abort.c:88
#9  0xb556f57d in __libc_message (do_abort=2, 
    fmt=0xb562c960 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#10 0xb55753c4 in malloc_printerr (action=2, 
    str=0xb5629737 "corrupted double-linked list", ptr=0x83fff88)
    at malloc.c:5949
#11 0xb5575664 in malloc_consolidate (av=0xb5647140) at malloc.c:4860
#12 0xb557699f in _int_free (av=0xb5647140, mem=0x85a4a98) at malloc.c:4737
#13 0xb5576d2c in *__GI___libc_free (mem=0x85a4a98) at malloc.c:3625
#14 0xb570860d in operator delete (ptr=0x0)
    at /var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/libstdc++-v3/libsupc++/del_op.cc:49
#15 0xb674c2c8 in QMapData::continueFreeData (this=0x85a4a98, offset=8)
    at tools/qmap.cpp:86
#16 0xb675abf5 in QMap<int, int>::freeData (this=0x87cd0ac, x=0x85a4a98)
    at ../../include/QtCore/../../src/corelib/tools/qmap.h:599
#17 0xb675bf2b in QVector<QRegExpAutomatonState>::free (this=0x8423c3c, 
    x=0x87ccfd8) at tools/qmap.h:153
#18 0xb675605f in ~QRegExpEngine (this=0x8423c38) at tools/qvector.h:112
#19 0xb675c993 in QCache<QRegExpEngineKey, QRegExpEngine>::trim (
    this=0x83ce3e8, m=86) at tools/qcache.h:75
#20 0xb675cb1c in QCache<QRegExpEngineKey, QRegExpEngine>::insert (
    this=0x83ce3e8, akey=@0x860ea44, aobject=0x860e900, acost=14)
    at tools/qcache.h:189
#21 0xb675676f in invalidateEngine (priv=0x860ea40) at tools/qregexp.cpp:3269
#22 0xb67568b6 in ~QRegExp (this=0xb6b77a5c) at tools/qregexp.cpp:3414
#23 0xb6b0cdc8 in __tcf_6 ()
    at /var/tmp/portage/kde-base/kdelibs-4.1.0/work/kdelibs-4.1.0/kdecore/localization/kuitsemantics.cpp:1488
#24 0xb5537571 in *__GI_exit (status=0) at exit.c:75
#25 0xb552063d in __libc_start_main (main=0x8266080 <main>, argc=5, 
    ubp_av=0xbfa7fcf4, init=0x8294e50 <__libc_csu_init>, 
    fini=0x8294e40 <__libc_csu_fini>, rtld_fini=0xb7f725e0 <_dl_fini>, 
    stack_end=0xbfa7fcec) at libc-start.c:258
#26 0x080a1df1 in _start ()
#0  0xffffe424 in __kernel_vsyscall ()
Comment 1 caulier.gilles 2008-08-10 17:13:13 UTC
Please try with last code from svn. I think aready fixed.

Thanks in advance

Gilles Caulier
Comment 2 Oliver Putz 2008-08-10 19:16:58 UTC
Hi! As said: So far I did not find a way to reproduce this crash, so checking out the svn version wont really help. But if you say it was already fixed in svn, lets just close this bug as fixed; and if I should see this again in KDE-4.2 or later I'll just reopen...