Digikam 5.1 crashes reproducibly upon changing the size of an image. Unfortunately there is no stack trace, only the last message when starting through konsole: Scaling with darkness 0, saturation 15783, and multipliers 2,312500 1,000000 1,628906 1,000000 digikam.rawengine: LibRaw progress: Scaling colors pass 1 of 2 digikam.rawengine: LibRaw progress: Pre-interpolating pass 0 of 2 digikam.rawengine: LibRaw progress: Pre-interpolating pass 1 of 2 Bilinear interpolation... digikam.rawengine: LibRaw progress: Interpolating pass 0 of 3 digikam.rawengine: LibRaw progress: Interpolating pass 1 of 3 digikam.rawengine: LibRaw progress: Interpolating pass 2 of 3 digikam.rawengine: LibRaw progress: Converting to RGB pass 0 of 2 Converting to sRGB colorspace... digikam.rawengine: LibRaw progress: Converting to RGB pass 1 of 2 digikam.rawengine: LibRaw: data info: width= 6016 height= 4016 rgbmax= 255 digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.general: Final "Bildgröße ändern" started... digikam.dimg: Cannot allocate buffer of size 3764662740 KCrash: Application 'digikam' crashing... KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 Unable to start Dr. Konqi memory status: locutus:/home/thommie # free -m total used free shared buffers cached Mem: 32116 26883 5233 8289 0 23867 -/+ buffers/cache: 3015 29101 Swap: 32763 0 32763
Sound like memory allocation failed to complete operation in editor. Did you use a 32 bits or 64 bits system ? Gilles Caulier
It is an OpenSUSE Leap 42.1 x64 with Kernel 4.1.27-27-default #1 SMP PREEMPT Fri Jul 15 12:46:41 UTC 2016 (84ae57e) x86_64 x86_64 x86_64 and 32 GB RAM Any idea how to debug without drkonqi? *-debuginfo packages are installed. Bye, Thommie
Maybe there is not enough RAM? But when I do the same resize operation on the same image with GIMP, there are no problems
Can you share the edited image somewhere on the cloud to test here ? Gilles Caulier
Hmmm, after some testing, I can not see this crash anymore and I don't know why ... Now I get the following lines: digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.dimg: "/mnt/nas/public/Fotos/Nikon D7200/DSC_0098.JPG" : JPEG file identified digikam.metaengine: Loading image history "" digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2016-05-08 14:39:21.000 CEST Qt::TimeSpec(LocalTime)) digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.general: Final "Bildgröße ändern" started... digikam.general: Final "Bildgröße ändern" completed... digikam.general: Free space available in Editor cache [ "/home/thommie/.cache/digikam/" ] in Mbytes: 946328 digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.widgets: Profile white point : x= 0.312713 y= 0.32912 Y= 1 digikam.widgets: dkCmsReadICCMatrixRGB2XYZ(2): [ 0.435852 , 0.38533 , 0.143021 ] [ 0.222382 , 0.717041 , 0.0605927 ] [ 0.013916 , 0.0971375 , 0.713837 ] digikam.widgets: d->Primaries.Red : X= 0.461196 Y= 0.232948 Z= 0.00978772 digikam.widgets: d->Primaries.Green : X= 0.415454 Y= 0.719903 Z= 0.0802877 digikam.widgets: d->Primaries.Blue : X= 0.115485 Y= 0.0520762 Z= 0.536577 digikam.general: Clearing LT true Maybe just a temporary "hickup". On /home/thommie in general I have 925G free space, that should be sufficient for this cache ...
... half an hour later, same situation: ... digikam.dimg: "/mnt/nas/public/Fotos/Nikon D7200/DSC_0234.JPG" : JPEG file identified digikam.metaengine: Loading image history "" digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2016-08-09 15:46:10.000 CEST Qt::TimeSpec(LocalTime)) digikam.dimg: No X.org XICC profile installed for screen 1 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.metaengine: Cannot set Iptc tag string into image using Exiv2 (Error # 8 : Value not set digikam.general: Final "Bildgröße ändern" started... digikam.dimg: Cannot allocate buffer of size 2367947736 Unable to start Dr. Konqi I uploaded the file to my Owncloud, you can download it there, Password "digikam51" https://www.netzwissen.de/owncloud/index.php/s/FhxJlfkucJ3XKAK (picture is from the refugee camp where I do some volunteer work)
>digikam.general: Final "Bildgröße ändern" started... Want mean that you have used resize tool. Which new image sizes do you set exactly ? Gilles Caulier
Original size is 6000 x 4000 (comes from the camera in jpeg "basic" quality) with 300 dpi resolution. I tried to resize it to 900 width and 480 width (for web publishing)
Ok, now i can reproduce the poblem. In fact there are 2 dysfunctions : 1/ when you enter 900 and 480 as new size, the value is set to maximum. This is a bug in value slider. 2/ As the values are set to max, the memory allocated is incredible huge, and of course cannot be allocated. The crash due to memory allocation failure must never appear because we catch memory allocation exception. Typically, an error message must appear instead a crash. Maik, for 1/ i remember that you patch something about the value slider widget before 5.0.0. Right ?
For point 1/ i understand the dysfunction: When we enter a value by a right mouse click over slider, if we press tab to switch to next value to enter, the new value is not set. Enter key must be pressed to validate... Thomas, this is how you set the new size values ? Anyway, other manner to change size values, for ex, directly by the slider are valid, and digiKam do not crash. Gilles Caulier
I can not really reproduce the problem. Should Tab key accept new value? Only a click with the left mouse button is critical because of the slider to a high value can jump to the mouse pointer position. Maik
I think they have 900% and 480% entered in the bottom two sliders? That's about right with the requested memory. Maik
Maik, If you test with standard QSlider and QSpinBox solution, The tab key valide the edited value. If Thomas as used the ration in % instead the real size in pixels to adjust image size, it's normal to fill up all memory in this context. Try Gimp to resize an image with high value. A warning appear to said that sizes will exceed all available memory. Gilles
Found a bug in checkAllocation() std::numeric_limits<int>::max() //else on 64bit only 32bit max value right is: std::numeric_limits<size_t>::max() Maik
and this will explain why the allocation error do not appear... Gilles
Git commit 90f31456779f4aeb9ac06a385f398827fd35c985 by Maik Qualmann. Committed on 11/08/2016 at 19:43. Pushed by mqualmann into branch 'master'. fix check of maximum addressable memory on 64bits M +1 -1 libs/dimg/loaders/dimgloader.cpp http://commits.kde.org/digikam/90f31456779f4aeb9ac06a385f398827fd35c985
Git commit 6ecfecf1f46970bfbd509fba50e9fa7c6b324309 by Maik Qualmann. Committed on 11/08/2016 at 21:13. Pushed by mqualmann into branch 'master'. new value is accepted with tab key in dslider input M +8 -0 libs/widgets/common/dsliderspinbox.cpp http://commits.kde.org/digikam/6ecfecf1f46970bfbd509fba50e9fa7c6b324309
I received digikam 5.1.0-149.1 from OpenSUSE/KDE_Extra repo today, tested with various 6000 x 4000 px images, resized to 800 px, no crashes any more. Well done ;-)
Git commit 65fa04ca097d4ff695690886a9f2be459b4279a9 by Maik Qualmann. Committed on 12/08/2016 at 19:29. Pushed by mqualmann into branch 'master'. fix crash by big memory allocation for DImg on 64bit M +4 -4 libs/dimg/dimg.cpp M +1 -1 libs/dimg/dimg.h M +1 -1 libs/dimg/loaders/dimgloader.cpp http://commits.kde.org/digikam/65fa04ca097d4ff695690886a9f2be459b4279a9
Maik, Coverity scan report a problem with your last patch. See below : ** CID 1369583: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /home/gilles/Devel/5.x/core/libs/dimg/loaders/dimgloader.cpp: 166 in Digikam::DImgLoader::checkAllocation(long long)() ________________________________________________________________________________________________________ *** CID 1369583: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /home/gilles/Devel/5.x/core/libs/dimg/loaders/dimgloader.cpp: 166 in Digikam::DImgLoader::checkAllocation(long long)() 160 m_image->m_priv->width = 0; 161 m_image->m_priv->height = 0; 162 } 163 164 qint64 DImgLoader::checkAllocation(qint64 fullSize) 165 { >>> CID 1369583: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(quint64)fullSize > 18446744073709551615ULL /* std::numeric_limits<unsigned long>::max() */" is always false regardless of the values of its operands. This occurs as the logical operand of if. 166 if ((quint64)fullSize > std::numeric_limits<size_t>::max()) 167 { 168 qCWarning(DIGIKAM_DIMG_LOG) << "Cannot allocate buffer of size" << fullSize; 169 return 0; 170 } 171 Gilles
Git commit 8c2a48759c3b7ef16e14458d423ef7041481e501 by Maik Qualmann. Committed on 17/08/2016 at 17:56. Pushed by mqualmann into branch 'master'. fix CR #1369583 M +1 -1 libs/dimg/loaders/dimgloader.cpp http://commits.kde.org/digikam/8c2a48759c3b7ef16e14458d423ef7041481e501