| Summary: | Crashing when trying to export | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Blindauer Emmanuel <bugs.kde.org> |
| Component: | Plugin-WebService-Piwigo | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, frederic.coiffier, gerhard, knoxit.etc |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.2.0 | |
| Sentry Crash Report: | |||
| Attachments: | degug trace, gdb output, wireshark tcp protocol | ||
|
Description
Blindauer Emmanuel
2008-11-23 21:11:31 UTC
did this happend again? I really cannot reproduce it and looking at your bt seems a kdelibs bug. Yes, I'm still having this problem. my current versions are (mandriva cooker packages): kdelibs4-core-4.1.81-1mdv2009.1 (20081128 or later) libkipiplugins1-0.2.0-1.beta4.2mdv2009.1 libkipi6-4.1.81-1mdv2009.1 libkipiplugins1-0.2.0-1.beta4.2mdv2009.1 digikam-0.10.0-1.beta6 I've tried to remove settings from kipirc, but it keep crasing after settings values for the remote gallery Created attachment 30263 [details]
degug trace, gdb output, wireshark tcp protocol
I have the same problem: digikam opens the dialog with gallery (seems to go fine, see wireshark trace in my attachment), then crashes. debug trace is attached. digiKam version 0.10.0-rc1 (rev.: 910756) Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 support XMP metadata: Yes LibCImg: 129 LibExiv2: 0.18 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.1.96 (KDE 4.1.96 (KDE 4.2 RC1)) LibKExiv2: 0.6.0 LibKdcraw: 0.5.0 LibLCMS: 116 LibPNG: 1.2.27 LibQt: 4.4.3 LibRaw: 0.7.0-Alpha1 LibTIFF: LIBTIFF, Version 3.8.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble widget: pre 0.7 SVN LibGphoto2: 2.4.2 LibKipi: 0.4.0 SVN commit 911296 by adjam: CCBUG:175928 I really cannot reproduce this bug in my system. Anyway, I hope this little change could fix it.. Please, let me know if it's so. M +11 -5 gallerywindow.cpp M +18 -18 plugin_galleryexport.h WebSVN link: http://websvn.kde.org/?view=rev&revision=911296 With the currrent version of kipi-plugins (rc1), the bug is fixed. I thing this bug is a dupe of 172910 Reopening bug. Sorry about that, but I cannot reproduce it at all. With comment #6 I argued that it was fixed.. *** Bug 182954 has been marked as a duplicate of this bug. *** SVN commit 921581 by adjam: CCBUG: 175928 As said I cannot reproduce this bug at all. Looking at knowit backtrace, I tried fixing.. Please, let me know if it is so. M +4 -2 galleryitem.h M +30 -11 gallerywindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=921581 Something perhaps related: with the fix from #5, I can use the plugin, create directories on the gallery, but I'm unable to see them, even after reconnecting. the directory is correctly created as I see them on the web interface. upload works. ok, we might be getting closer i guess. NO MORE CRASHES or error message, but the directory structure is not displayed correctly. I can see the root directory and all of its first level sub-directories, but nothing from then on. @Andrea - I will give you temporary acces to my gallery and send you a private message now with the access info. maybe then you can reproduce what is happening here. pls let me know if there is anything else i can do. another thing i just noticed. If you click on the + icon next to the root album, it pops up the first level sub-directories, but if you double click on it, and thus force a refresh of the directory content I suppose, it lists no subdirectories and the + icon disappears. ok, did another test. double clicking on any folder/album does not cause function GalleryWindow::slotAlbums to be executed. I would think that it should be, no? hi andrea. i had a nother look. I THINK (pls correct me if I'm wrong) the problem is at this line in function GalleryWindow::slotAlbums QList<QTreeWidgetItem*> parentItemList = d->albumView->findItems(parentTitle, Qt::MatchExactly); My theory is that you assume that the list of albums and their parents are hierarchical, however, they are not! IDs of the albums increase as new albums are created, but you can have a newer album with a higher ID as a parent of an old album with a lower ID. so if you try to find the parent, which is only going to be scanned later on, there is no match, it can not add the children and the problem propagates. I didn't try to solve the algorithm outright, since i didn't want to duplicate efforts. Nima SVN commit 924664 by adjam: Fixing bug #175928. Try 1. CCBUG: 175928 M +38 -50 gallerywindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=924664 andrea, thanks for the fix. The directory structure now displays correctly and one can navigate through it using the plus expander signs next to the folder. HOWEVER, when one clicks on an album name, which you have to do in order to add photos or create albums, it tries to refresh the contents including the subalbums. At this point, the plus sign disappears and the subalbums are no longer displayed. I'm guessing it has something to do with "void GalleryWindow::connectSignals()"?? new albums are created correctly, BUT the entire tree is reloaded and one has to expand again to reach the point where the album was created. let me know if i can help. SVN commit 925060 by adjam: BUG: 175928 Bug Fixed! Now GalleryExport shows deep dirs & let user browsing them. Yeah! M +10 -9 gallerywindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=925060 |