May be relevant to mention that I have often used DNG converter before, but I just updated to Kubuntu 15.10. Also, the file to be converted is located on an external (usb) hard drive with ntfs file system.

It crash when it try to render a turn wheel over thumbnail while processing. see KPixmapSequence::frameAt() in trace. The wheel pixmap is null. This pixmap is taken from KDE icon sets. So it miss a package on your computer...

Gilles Caulier

*** Bug 354668 has been marked as a duplicate of this bug. ***

I had the same issue after upgrading from Kubuntu 15.04 to 15.10. It seems to be fixed when I change my icon set from Breeze/Breeze Dark back to Oxygen...
Is the wheel pixmap removed from Breeze/Breeze Dark icon sets?

yes, i think it removed.

In Qt5 port, we use an embeded version of pixmap in digiKam...

Gilles Caulier

Changing from Breeze to Oxygen (or any other theme) did not work for me so far. DNG still crashes.

*** Bug 355154 has been marked as a duplicate of this bug. ***

*** Bug 355744 has been marked as a duplicate of this bug. ***

*** Bug 355745 has been marked as a duplicate of this bug. ***

*** Bug 357149 has been marked as a duplicate of this bug. ***

*** Bug 357838 has been marked as a duplicate of this bug. ***

Created attachment 96635 [details]
New crash information added by DrKonqi

digikam (4.12.0) on KDE Platform 4.14.13 using Qt 4.8.6

- What I was doing when the application crashed:

I used the adjust date & time tool when the crash happened. Digikam was in the process of rewriting an EXIF timestamp of ~ 1700 files and reliably crashes after about 10%. Also, some updated files were corrupted.

-- Backtrace (Reduced):
#6  QPixmapData::isNull (this=<optimized out>) at image/qpixmapdata_p.h:131
#7  QPixmap::isNull (this=this@entry=0x476e768) at image/qpixmap.cpp:579
#8  0x00007f68b84ab96b in QPixmap::copy (this=this@entry=0x476e768, rect=...) at image/qpixmap.cpp:382
#9  0x00007f68b84ac6bf in QPixmap::QPixmap (this=0x7ffef6be9790, pixmap=...) at image/qpixmap.cpp:303
#10 0x00007f68b91b1f38 in KPixmapSequence::frameAt (this=0x25ccc48, index=1) at ../../kdeui/util/kpixmapsequence.cpp:143

*** Bug 358424 has been marked as a duplicate of this bug. ***

*** Bug 360770 has been marked as a duplicate of this bug. ***

I've experienced this bug in digikam 4.12 in the same way Yasin Zähringer described.

So I've followed the guide at https://www.digikam.org/download?q=download/GIT to get the latest digikam since this bug entry says "RESOLVED DOWNSTREAM" I thought that should fix it.

But now I have the problem that in this new version the menu entry that allowed for mass time stamp manipulation is gone. Or maybe moved? Please help.

The Time Adjust tool is not yet re-integrated in digiKam 5.0.0 after Qt5 port of application. It still in todo list. Please, be patient, we plan to do it before final release...

okey, thanks for the info! would getting digikam 4.14 to run on my system help? as in does it already contain the fix for this bug?

haha okey so that was a catastrophic experience ;) while digikam 4.12 managed to corrupt a single picture of my album while crashing, digikam 4.14 managed to corrupt around 20 of the total ~50 pictures in the album (selected all of them before using the adjust date/timestamp kipi plugin) But don't worry for me I have backups ;)

*** Bug 361102 has been marked as a duplicate of this bug. ***

I've got the desktop theme set to Oxygen and DK still crashes any time I process multiple images at the same time - adjust date/time, upload to google photos.
I've double checked that the Oxygen icons are selected and this didn't make any difference

Right now there is no version of DK which I can use. DK4 crashes all the time and DK5 isn't ready for production and needed features aren't there yet.

I challenge the status of this bug as "resolved". I think this needs to be fixed somehow for DK4.

No update will be done for digiKam 4.x. The next one is 5.0, which fix definitively this problem.

In fact it miss an image on your system, shared with Oxygen package : process-working.png

Gilles Caulier

(In reply to caulier.gilles from comment #21)
> No update will be done for digiKam 4.x. The next one is 5.0, which fix
> definitively this problem.

So anyone who has this problem has no usable version of DK until 5.0 is released?
My system is a relatively vanilla version of kubuntu wily which is why I guess a lot of people are being hit by this.

> 
> In fact it miss an image on your system, shared with Oxygen package :
> process-working.png

That's not correct as you can see here.

find /usr -name process-working.png
/usr/share/icons/Humanity/animations/16/process-working.png
/usr/share/icons/Humanity/animations/24/process-working.png
/usr/share/icons/Humanity/animations/22/process-working.png
/usr/share/icons/Humanity/animations/32/process-working.png
/usr/share/icons/oxygen/22x22/animations/process-working.png

On this kubuntu wily system, the following packages contain process-working.png;

$ apt-file search process-working.png | awk -F: '{ print $1 }'  | uniq
elementary-icon-theme
gnome-accessibility-themes
gnome-icon-theme-full
gnome-theme-gilouche
humanity-icon-theme
kde-icons-mono
mate-icon-theme
moblin-icon-theme
oxygen-icon-theme
scilab-data
sparkleshare
tango-icon-theme
xubuntu-icon-theme

If I try to install that list, apt-get reports that;

humanity-icon-theme is already the newest version.
oxygen-icon-theme is already the newest version.

I didn't install all of them as doing so would bring a long list of other stuff with it.

Continuing to investigate, I had a look at how digikam attempts to find process-working.png.

The attached file, /tmp/not-finding-process-working-png.txt, is the results of running digikam with 'strace' and then searching the results of that with grep for process-working.

You can see that it's attempting to find process-working.png in many places but not under /usr/share/icons/Humanity or /usr/share/icons/oxygen which is where it would find it.

Indeed, there are no references to either /usr/share/icons/Humanity or /usr/share/icons/oxygen in the strace output at all. 

I think there's a mis-configuration somewhere and from the number of people finding this problem, it's not just be. 

I don't know enough about KDE or Qt to know how the paths for icons are configured.

Created attachment 98159 [details]
trace showing digikam is looking in the wrong places for process-working.png

Results of 'grep process-working /tmp/abc >/tmp/not-finding-process-working-png.txt' where /tmp/abc is the results of 'strace -f digikam |& grep png >& /tmp/abc'.

Created attachment 98161 [details]
failed attempts to access process-working.png when theme is oxygen

I've now set the theme to oxygen (which contains process-working.png), rebooted and the crash still happens. The attached file, process-working-not-found-oxygen-theme.txt, shows that digikam is still looking in breeze for process-working.png and not in oxygen.
This reinforces my suspicion that there is a bug somewhere in how digikam decides where to look for icons.

The way to find this PNG file is delegate to KDE API, through KIcon class.

Gilles Caulier

My other PC doesn't have this problem but it also has process-working.png in 2 extra places as can be seen here.

find /usr -name process-working.png
/usr/share/kipiplugins/pics/process-working.png
/usr/share/icons/Humanity/animations/32/process-working.png
/usr/share/icons/Humanity/animations/16/process-working.png
/usr/share/icons/Humanity/animations/22/process-working.png
/usr/share/icons/Humanity/animations/24/process-working.png
/usr/share/icons/oxygen/22x22/animations/process-working.png
/usr/share/digikam/data/process-working.png

Looking at where these came from, I find this;

$ dpkg -S process-working.png
humanity-icon-theme: /usr/share/icons/Humanity/animations/16/process-working.png
humanity-icon-theme: /usr/share/icons/Humanity/animations/24/process-working.png
oxygen5-icon-theme: /usr/share/icons/oxygen/22x22/animations/process-working.png
digikam5-data: /usr/share/digikam/data/process-working.png
humanity-icon-theme: /usr/share/icons/Humanity/animations/22/process-working.png
humanity-icon-theme: /usr/share/icons/Humanity/animations/32/process-working.png
kipi-plugins5-common: /usr/share/kipiplugins/pics/process-working.png

So I guess it's accidental that it works on my 2nd PC because I have the beta of DK5 install there.

So here is my work-around for the machine where DK crashes;

1. cd ~/.kde/share/apps/digikam
2. mkdir toolbar (assuming it doesn't already exist)
3. cp  /usr/share/icons/oxygen/22x22/animations/process-working.png toolbar

I've checked this with the UI for modifying dates/times on images and the UI for uploading to Google and both now work where they previously crashed.

brilliant! thanks jon33040!

your workaround worked for me too - I'm running Ubuntu Mate 16.04 beta with a Cinnamon desktop with Digikam 4.14 installed from this repository https://launchpad.net/~philip5/+archive/ubuntu/extra

I tried the workaround given by jon33040. Unfortunately, it does not work for my system (Kubuntu 15.10, KDE Plasma version 5.4.2 with Digikam 4.12.0).

(In reply to D. van Aken from comment #31)
> I tried the workaround given by jon33040. Unfortunately, it does not work
> for my system (Kubuntu 15.10, KDE Plasma version 5.4.2 with Digikam 4.12.0).

Running digikam from the command line with this recipe will print the directories where it is looking for process-working.png. You can then try copying process-working.png to one of those directories.

strace -f -e access digikam |& grep process-working | grep -v /usr/

What it prints on my laptop is the following;

pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0
[pid 10844] access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png", R_OK) = 0

and so on

Hence the directory in the work-around in comment 29.

(In reply to jon33040 from comment #32)
> (In reply to D. van Aken from comment #31)
> > I tried the workaround given by jon33040. Unfortunately, it does not work
> > for my system (Kubuntu 15.10, KDE Plasma version 5.4.2 with Digikam 4.12.0).
> 
> Running digikam from the command line with this recipe will print the
> directories where it is looking for process-working.png. You can then try
> copying process-working.png to one of those directories.
> 
> strace -f -e access digikam |& grep process-working | grep -v /usr/
> 
> What it prints on my laptop is the following;
> 
> pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> [pid 10844]
> access("/home/jon/.kde/share/apps/digikam/toolbar/process-working.png",
> R_OK) = 0
> 
> and so on
> 
> Hence the directory in the work-around in comment 29.

That was the golden hint! Thank you!
In my case, the output was like:
[pid  2296] access("/home/dirk/.kde/share/icons/hicolor/48x48/apps/process-working.png", R_OK) = -1 ENOENT (No such file or directory) 
[pid  2296] access("/home/dirk/.local/share/icons/hicolor/48x48/apps/process-working.png", R_OK) = -1 ENOENT (No such file or directory) 
[etc.; it was also looking for process-working.svg, process-working.xpm]

The source directory to get process-working.png was: /user/share/icons/mono/48x48/animations
(and similar directories 16x16 and 128x128)
The directory /usr/share/icons/oxygen/48x48/animations/ contained a similar file: process-working-kde.png

After copying the  correct files to ~/.kde/share/icons/hicolor/16x16/apps/  and to the 48x48 and 128x128 versions, DNG convertor works again!

*** Bug 361312 has been marked as a duplicate of this bug. ***

*** Bug 361802 has been marked as a duplicate of this bug. ***

*** Bug 362104 has been marked as a duplicate of this bug. ***

*** Bug 384200 has been marked as a duplicate of this bug. ***

*** Bug 388542 has been marked as a duplicate of this bug. ***

*** Bug 407203 has been marked as a duplicate of this bug. ***

Not reproducible with 7.0.0-beta1