https://bugs.kde.org/show_bug.cgi?id=426175
--- Comment #45 from caulier.gil...@gmail.com --- Marcel, from your comment #41 : >I just uploaded the comparison of two appimages (normal and debug). I stopped >>digikam searching for faces manually before running out of memory because I >was >not able to take a screen shot after running out of memory. My computer >was not >reacting any more. That is nasty. Both were taken after a restart of >the >computer because after the crash the swap is still in use. So I got a >cleaner >record Your system do not have enough free meory to run properly. It's normal. You reach the limits. >Personally I can't see any significant difference. As expected. >Why and when should I take a backtrace? The backtrace with GDb can be done with Appimage to pass "debug" as argument in command line when you start the AppImage bundle. This will run digiKam in GDB. When it crash, enter "bt" in GDB shell. >Where can provide the debug argument? There is no such argument on appimages. In the bundle, there is a bash script to catch arguments. I written the script as AppImage SDK do not provide this kind of feature, even if i talk with AppImage lead developer, but he won't to support this as i know. Note : just for info : the official AppImage target builder tool from the SDK is unable to compile the bundle. I reported this problem to the AppImage project, which responded that the target application is to huge to be processed. Seriouly ! AppImage has used bash scripts in the pass and all work as expected. They convert all bash script to C program, and now nothing work: the program crash. As usual, developer use this kind of excuse to not fix the real problem... Read the story here: https://github.com/probonopd/linuxdeployqt/issues/359 This is why all the digiKam AppImage build process run through bash scripts that i written. There is no stupid limit. >I have the following pics in my lib: >BMP: 13 >GIF: 4 >JPEG: 1 >JPG: 59875 >PNG: 758 >PSD: 2 >TIFF: 1 >So I guess the leak must come at least with JPG or png pictures. JPG probably, i think. It can be also a problem with libjpeg-turbo which try to optimize also the JPEG processing using GPU. If it true, decoding/encoding JPEG images with BQM for ex can be a try to check if the problem exists. Gilles -- You are receiving this mail because: You are watching all bug changes.
