Bug 168839

btw this happens after every tagging

The crash is not very unstructive. It sound like a broken package... update or compile digiKam yourself and try again. (the crash is not reproductible here)

Thanks in advance

Gilles Caulier

Gilles,

I can confirm this, too. It happens when deleting "assignTagsPopup". But for me digiKam code looks normal... strangely it doesn't happen when deleting "removeTagsPopup"... I will compare the code line by line to find any difference.

Andi

Hmm there is nothing to compare at all, both items are the same class (TagsPopupMenu) and both are initialized identically. I have no clue what is happening here. I changed the deletion order of the two TagsPopupMenu objects, but still it crashes when deleting "assignTagsPopup". So it is not an issue of the removal order.
Since both objects are QObject classes, can't we just remove those delete lines? I thought Qt will handle it be itself and you should never use delete on such objects. When removing those lines, it is working again. Maybe we delete too much here?

Andi

Created attachment 26766 [details]
fix

Do we really need to delete Q objects here? Without it everything works fine
again...

Andi

Andi,

No, we don't need to delete these items here using QT4. I think this code is sequel from Qt3 version of digiKam which can give a side effect in Qt4. I think we have another code like this to remove later, if another report like this are registered.

So for me, it's fine to apply your patch. Just to be sure, try with valgrind if no memory leak appear. If no. go ahead (:=)))

Gilles

I always thought Q objects (Qt3 and Qt4) are never removed by the user via the delete command, but removing the four lines in the above patch will create memory leaks.
I don't understand why I can delete the removeTag menu but not the assign tag menu... it always crashes. Maybe it is not working because TagsPopupMenu doesn't have a parent widget in the constructor...

Created attachment 26782 [details]
still crashing

I don't know what to do about this... I changed all TagPopupMenu lines in this
patch and removed the "new" operator.
Still it crashes and the stack trace tells me that it is trying to delete a
TagPopupMenu (and strangely it calls ~QMenu twice...).

Gilles, Marcel,

any idea? It shouldn't crash now because the menus are not called with new
anymore and the KActions also have a parent, so they should be removed
correctly by Qt itself.
The good thing: No memory leak anymore :-) But with digiKam crashing this is a
bad compromise.

Ferdinand,

do you have upgraded Qt in the last time? I did so on 07-08-2008 from Qt 4.4.0 to 4.4.1. Maybe this is the reason? For me it looks like a Qt problem, not a digiKam problem because whatever I do here it crashes, although no memory leaks or null pointer issues can be detected.
What Qt version are you running? If you also have 4.4.1 installed, we might have to contact Trolltech about this.

here I have libqt4-4.4.1-6.1

Do you know when you have updated it from 4.4.0 to 4.4.1?
Gilles, do you run Qt 4.4.0?
So maybe this is an Qt issue, because the source code looks alright, and if you remove all "new" operators and create "normal" objects, it still crashes, although these objects should be deleted correctly when leaving the slot.

Andy,

Sorry for the delay. I'm just back from Akademy. A great event. Last time, you and Marcel you must come to this event and present your work into digiKam project (:=)))

Here i use Qt 4.4.1 with unstable Mandriva 2009-beta1 + cooker repository (KDE 4.1).

else, stable Mandriva 2008.1 use Qt 4.3.3 (KDE 4.0.3)

Gilles

Nice that you had a great time... normally I would have been on my way to 
norway now :-( but you know my car also is broken... damn... (so there is no 
holiday or Akademy this year). But maybe next time I will be able to come to 
Akademy... 

Damn so this is no Qt problem? I don't get it. This is very strange, even with 
this new patch it will crash (although it shouldn't, but maybe I'm wrong 
here, memory management has never been the topic I'm good at, I come from a 
python background where you don't have to deal with those things...).

And I still don't get why it calls ~QMenu() twice, although the TagPopupMenus 
have no children... so what is it doing... hmm... and why only assignTagsMenu 
and not the other...? question upon question... :-)

Andi

Andi,

In case of crash, what valgrind backtrace report exactly ?

If crash appears about delete operation, the backtrace come from internal Qt4 or still into digiKam code ?

Gilles

This is what I get from valgrind:

==10925== Invalid read of size 4
==10925==    at 0x5DE73F2: QWidgetAction::releaseWidget(QWidget*) (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x60EA774: QMenu::~QMenu() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x58D0324: QObjectPrivate::deleteChildren() (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x5DE294A: QWidget::~QWidget() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x60E8377: QMenu::~QMenu() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x82F736E: Digikam::TagsPopupMenu::~TagsPopupMenu() (tagspopupmenu.cpp:404)
==10925==    by 0x8228ED0: Digikam::AlbumIconView::slotRightButtonClicked(Digikam::IconItem*, QPoint const&) (albumiconview.cpp:797)
==10925==    by 0x82295A2: Digikam::AlbumIconView::qt_metacall(QMetaObject::Call, int, void**) (albumiconview.moc:190)
==10925==    by 0x58D48D6: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x58D4DEC: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x82AFF66: Digikam::IconView::signalRightButtonClicked(Digikam::IconItem*, QPoint const&) (iconview.moc:113)
==10925==    by 0x82B2834: Digikam::IconView::contentsMousePressEvent(QMouseEvent*) (iconview.cpp:953)
==10925==  Address 0xa22596c is 4 bytes inside a block of size 12 free'd
==10925==    at 0x402272A: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10925==    by 0x82FAE1B: Digikam::TagToggleAction::~TagToggleAction() (tagspopupmenu.cpp:69)
==10925==    by 0x58D0324: QObjectPrivate::deleteChildren() (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x58D7A03: QObject::~QObject() (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x5D970AF: QActionGroup::~QActionGroup() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x58D0324: QObjectPrivate::deleteChildren() (in /usr/lib/libQtCore.so.4.4.1)
==10925==    by 0x5DE294A: QWidget::~QWidget() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x60E8377: QMenu::~QMenu() (in /usr/lib/libQtGui.so.4.4.1)
==10925==    by 0x82F736E: Digikam::TagsPopupMenu::~TagsPopupMenu() (tagspopupmenu.cpp:404)
==10925==    by 0x8228ED0: Digikam::AlbumIconView::slotRightButtonClicked(Digikam::IconItem*, QPoint const&) (albumiconview.cpp:797)
==10925==    by 0x82295A2: Digikam::AlbumIconView::qt_metacall(QMetaObject::Call, int, void**) (albumiconview.moc:190)
==10925==    by 0x58D48D6: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/libQtCore.so.4.4.1)


It is the same backtrace as from GDB.

I used valgrind with those options:

valgrind  --tool=memcheck --leak-check=yes --db-attach=yes --suppressions=digikam4.sup /usr/bin/digikam

Andi,

Sound like a similar problem that i have fixed in a past with this commit :

http://websvn.kde.org/?view=rev&revision=787473

Using deleteLater() must fix the problem

Gilles

Andy,


>And I still don't get why it calls ~QMenu() twice, although the TagPopupMenus
>have no children... so what is it doing... hmm... and why only assignTagsMenu
>and not the other...? question upon question... :-) 

Well it's simple to understand: it's a race condition with Qt when it delete internal menu contents. If menu is big it take a while else it's very fast.

When we delete menu in digiKam before than Qt have deleted internal component, we have a crash. Note this problem is specific to Qt4. With Wt3 i have never seen that.

There is a lots of place where tagpopupmenu is used and deleted by hand. All these codes need to be fixed by this way.

Gilles

Gilles,

I'm sorry but this doesn't seem to fix the problem, I just tried it. But maybe 
I need to call this on the popupmenu (the main menu so to say)...? I'll try 
this, too.

Ok now it seems to work... I removed the "new" operator again, removed all delete lines and just call deleteLater() on popupmenu...

SVN commit 845962 by aclemens:

this fix should prevent a race condition when deleting the context popup menu

CCBUGS:168839

 M  +35 -38    albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=845962

Ah damn it is not working when using "normal" objects... strange... all the 
other menus are not defined with "new" operator and they work. I'll commit 
the fixed version WITH the "new" operator now.

Ferdinand,
can you please test the latest SVN to see if it is fixed?

Any updates here?
Ferdinand, is it fixed for you so we can close this one?

Andi

kde4-digikam-0.10.0-16.13 SuSE 10.3

I even didn't tag a pciture, I just clicked somewhere between the images 

QPainter::begin: A paint device can only be painted by one painter at a time.
QPainter::begin: A paint device can only be painted by one painter at a time.
KCrash: Application 'digikam' crashing...
sock_file=/home/kdesvn/.kde4/socket-cc-gf2/kdeinit4__0

Created attachment 26952 [details]
trace

I can't confirm this... you clicked between the thumbnails and digiKam crashed? Right now? With the current SVN checkout?
Left- or Right-click?

Andi

>QPainter::begin: A paint device can only be painted by one painter at a time. >KCrash: Application 'digikam' crashing... >sock_file=/home/kdesvn/.kde4/socket-cc-gf2/kdeinit4__0

Ferdinand : i have fixed normally this problem with current implementation from svn (0.10.0-beta3)

Gilles Caulier

SuSE Factory has beta 2 currently - should be picked up soon I assume.
I'll check then.
Or pls provide the link to SVN, don't have time to search now

Ferdinand,

Look here : http://www.digikam.org/drupal/download/svn

Gilles Caulier

Gilles,

but the QPainter issue shouldn't be the problem here, I also had this a lot but digiKam never crashed. Maybe I'm wrong... 

Ferdinand,
you said you are using beta2? So you can't have this patch installed yet. As Gilles mentioned, please try to compile for yourself or wait for beta3 from openSUSE...

Andi

Version 0.10.0-beta3 (rev.: 850265) works for me
thanks - it's really a great tool .....

BTW IMHO the tag bar (left side) shouldn't have a fixed minimum width

Since we patched it FIXED should be used instead of WORKSFORME.