GNOME Bugzilla – Bug 719723
Drag and drop of sRGB image crashes GIMP
Last modified: 2016-04-17 16:39:55 UTC
when drag n drop pic, gimp crashes seems app cant eat the color profile
Created attachment 263340 [details] jpg
Hi, Thanks for the report. I could not reproduce your crash, whatever with gimp-2-8 branch and master, on Linux. On gimp-2-8, I do get some errors on terminal about problematic XMP metadata and a message about what seems to be a duplicate (?) profile though: --------------- While parsing XMP metadata: Error on line 70 char 1: End of element <exif:Flash> not expected in this context Metadata parasite seems to be corrupt lcms: skipping conversion because profiles seem to be equal: sRGB IEC61966-2.1 sRGB built-in ---------------- If the source of the crash is the EXIF data, well it seems fixed on GIMP master where we have a new metadata handling system, because I don't see any error there and I can inspect the metadata with the new dialog. The problem still exists on gimp-2-8 but I don't know if anyone will take the time to fix this while we know all this code will soon be gone with the next major release. If the source of your crash is indeed the profile issue, maybe the lcms library reacts differently on Mac than Linux and there is something to fix indeed because GIMP should not crash. I have not investigated the code much further though. What made you think the crash was the color profile in particular? Did you get any error messages? If so, could you write them down here? Maybe you can also test to remove the profile and see if GIMP loads the image just fine. For instance with ImageMagick, you can run the `convert` command with "+profile icc" and it should remove the profile labelled "sRGB IEC61966-2.1" (don't use the -strip option! It would remove all metadata apparently, and that would not help the diagnosis on whether the problem is on the profile or the rest of the metadata). See http://www.imagemagick.org/script/command-line-options.php#profile *ATTENTION*: I guess you don't want to overwrite the same file inline! You want to create a new jpeg without the profile and keep the original! Check out the `convert` manual before you try random conversion. Of course you can also use any other program able to strip out profiles for the same effect. Then tell us if GIMP is able to open the image without no profile. Thanks.
Hi again Slava, Recently released GIMP 2.8.10 has a bugfix relative to a crash on a missing RGB profile. Maybe this is related and it would fix your issue too. Could you please install the last version (2.8.10) and report back to us? Thanks.
Sorry Friend dont have Xcode. I havent install 10.9 yet, chkd reviews today and still see no progress. i got 2011 MBR fully lock n load, I often hear facts (including old fellas) that perverts from CA make such new OS with system performance decreasing n battery life down to push users to buy new models intentionally. Missing backup feature alludes too. SO Friend, if u suggest how to cook tar.bz2 i run it immediately. For my profile guess -just idea, i worked with plenty files - all went smooth. (In reply to comment #3) > Hi again Slava, > > Recently released GIMP 2.8.10 has a bugfix relative to a crash on a missing RGB > profile. Maybe this is related and it would fix your issue too. > > Could you please install the last version (2.8.10) and report back to us? > Thanks.
Hello Slava, I am sorry, but I did not really understand your last message. When you say "i worked with plenty files - all went smooth", are you saying you updated GIMP to the last version (2.8.10) and it does not crash anymore? If so, I guess this report is to be closed as fixed. :-)
Slava, can you try the latest 2.8.10 dmg and report back please?
This bug still seems to be present in the 2.8.10 release on OS X 10.9 Mavericks. Anything I can do to help?
Yes could you please run GIMP in gdb and get us a stack trace of the crash?
Sorry, As I'm not on my stand OS (win7-64) and I am on OSX 10.9, I don't remember how to do that. Sorry again, Ward
The same thing happens on my mac. I have Maverick OS, I created a screenshot, and then with the Finder went to Desktop and dragged the screenshot to Gimp. Each time I do that - Gimp crashes. I installed Gimp 2.8.10.
Yoav, or anyone else encountering such trace, could you please provide the stack trace of the crash please? Thanks.
Can you please explain how it can be done? I'm not that expert in mac...
Hi Yoav, You'll find all the explanation on this link: https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details#obtain-a-stacktrace Thanks!
I've fixed this bug (and some others too) by more or less completly rewriting the gtk-osx-integration library. The current implementation of gtk-osx-integration uses an undocumented Cocoa function call to build the menu programtically and therefor needs to wait until the application has finished setting up the menus. After the menus have been set up, the Cocoa core gets informed that the application has finished launching. This made it necessary in GIMP to register a separete event handler for drag and drop events in addition to the use of the application delegete methods. This double event handling somehow triggers this bug. By rewriting the library to use pure documented Cocoa and not to hide the delegate and notification protocols, I got the chance to inform the Cocoa code much ealier about finished launching, and could use the application delegate object to completly handle all open file events. This completly fixed this bug. I'll update my repository with the new library as soon as possible and of course will send the whole code to upstream as well.
Nice to hear it! Thanks Simone. We are looking forward your patch about this then. :-)
Sorry all. Ended up moving and also severely damaging my shoulder this winter. Finally able to use it again so I apologize. Any idea about a time stamp for this fix?
Should we move this bug to GTK+ then, if it has to be solved there anyway?
Hi Michael, Maybe I missed something, but I don't think it has been said it has already been solved in GTK+. From the history of this report, last relevant info was that Simone said she had a patch ready for this specific problem. Though maybe you meant that gtk-osx-integration is Simone's fork of GTK+? In this case, yes this report should be relabelled. In any case, Simone, what is the status of this? Would it be possible to upload your patch here? Have you done so already on a separate report? (in this case, which bug id?) Thanks!
I tried today with my GIMP 2.8.11 build of the build-osx branch which is based on GIMP 2.8 (commit c4dc168 from 25.05.2014) and uses lcms 1.19. I can confirm that GIMP doesn't crash anymore. It still shows the error message from comment 2, but keeps running. For the GIMP users this means that it should work in the next release GIMP 2.8.12.
friend,pls give link to files (In reply to comment #19) > I tried today with my GIMP 2.8.11 build of the build-osx branch which is based > on GIMP 2.8 (commit c4dc168 from 25.05.2014) and uses lcms 1.19. > I can confirm that GIMP doesn't crash anymore. It still shows the error message > from comment 2, but keeps running. > For the GIMP users this means that it should work in the next release GIMP > 2.8.12.
I've already posted this to the devel list, but to keep the bug tracker in sync... I’ve just uploaded my patched version of the gtk-mac-integration library and committed it into my svn repository. https://sourceforge.net/p/gimponosx/code/HEAD/tree/gtk-mac-integration/ The README gives some information about why I did this, as I already mentioned in my above quoted posting, and gives some basic documentation about how to use the library. I’ve patched GIMP’s 2.8.10 sources to use this forked library. The changes are in app/gui/gui.c and app/gui/gui-unique.c. You can find the patches in my svn too at https://sourceforge.net/p/gimponosx/code/HEAD/tree/GimpPorts/ports/graphics/gimp2/files/
The source is here: https://git.gnome.org/browse/gimp?h=osx-build. It is work in progress and planned to be in the upcoming 2.8.12 release. Please be a bit patient. If you want to build yourself for OS X, you can get the sources from the link above. Be sure to pull the osx-build branch.
Does this still happen with 2.8.14?
... or 2.8.16?
With GIMP 2.8.16 on OS X 10.11, GIMP itself does not crash, but the file-jpeg plugin does. The error that is shown is similar: ** (file-jpeg:41748): WARNING **: JPEG - unable to decode XMP metadata packet lcms: skipping conversion because profiles seem to be equal: sRGB IEC61966-2.1 sRGB built-in
With GIMP master no error is shown and the plugin does not crash.
The error message shown by the file-jpeg plugin has been fixed in gimp-2-8. Note that this message was only shown if the metadata plugin was not built, which is not built when libexif is not available. It's probable that the error message generated by the plugin made you believe that Gimp had crashed. commit 5abf0bb35763fb3ebe56bd96298f852adb423e51 Author: Kristian Rietveld <kris@loopnest.org> Date: Sun Apr 17 17:22:12 2016 +0100 Bug 719723 - Drag and drop of sRGB image crashes GIMP In file-jpeg, move the HAVE_LIBEXIF define down to include the call to the metadata plugin (pdb-in-metadata-decode-xmp). This is necessary because the metadata plugin is only available if GIMP was configured with HAVE_LIBEXIF.