GNOME Bugzilla – Bug 165342
Crash on "mode -> indexed color" when pasted layer hasn't been anchored
Last modified: 2008-01-15 12:46:34 UTC
To reproduce with Gimp 2.2.2: 1. open image 2. select a rectangular portion 3. copy 4. new file (with copied dimensions) 5. paste 6. mode -> indexed color CRASH! to avoid, anchor the pasted layer between steps 5 and 6.
This looks like it is probably related to bug #163879, but the crash occurs for me as described using cvs HEAD, where that bug is supposedly fixed.
Works fine with 2.2.3 on Win32.
Works fine for me using CVS HEAD.
I was misled because it happened the first time I tried, but this is actually pretty tricky to reproduce. There seem to be two things required to make it crash: first, the image in step 1. is indexed; second, the region copied does not contain the color white (the background color produced by "New Image"). When these things happen, the procedure reliably produces Gimp-Core-ERROR **: Non-existant colour was expected to be in non-destructive colourmap. aborting... followed by a crash.
Created attachment 36627 [details] example test.xcf file to produce crash I can reliably crash GIMP by following the procedure as described using this file (which already contains a selection).
It's not really a crash. You are running into an assertion and the code calls g_error(). Adding Adam to Cc: since he presumably added that assertion in the first place. As a quick fix, it should probably be made a g_warning().
Indeed that's a shouldn't-happen case. Strangely, if the 'new image' isn't the same size as the copied region, no error. I can only guess why this is happening, but until I get to it (maybe around when hell freezes over) this is the (untested) relatively-safe quickfix. Not a real patch because I don't have anything near HEAD, and have lots of other stuff in my gimpimage-convert.c anyway. @@ -3287,8 +3395,14 @@ goto got_colour; } } - g_error ("Non-existant colour was expected to " - "be in non-destructive colourmap."); + g_warning ("Non-existant colour was expected to " + "be in non-destructive colourmap."); + /* The above does seem to actually happen in real life + (bugzilla bug 165342). Here's a workaround. */ + lastred = src[red_pix]; + lastgreen = src[green_pix]; + lastblue = src[blue_pix]; + lastindex = 0; got_colour: dest[INDEXED_PIX] = lastindex; if (has_alpha)
It seems that the problem here is not actually in the mode-conversion code, it is a deeper problem relating to pasting layers. It looks like pasting a layer that completely overlaps the image causes something to go wrong with the layer list, so that the layer beneath the floating layer is sometimes omitted. Attached below, for example, is an xcf image I constructed by pasting a solid-colored layer on top of two other solid-colored layers, and then playing around with visibility. Try converting the floating layer to a new layer and watch what happens in the layers dialog.
Created attachment 36669 [details] test2.xcf Convert the floating selection into a new layer and watch the layers dialog.
You are pasting to an invisible layer, so the floating selection is invisible too (because it is a preview of how it will look after pasting). When creating a new layer from it, its own visibility state is taken into account and it shows up. This is exactly how it is supposed to work. The actual problem is the general we-need-a-new-ui-for-floating-selections bug.
Yes, but look at the previews in the Layers Dialog -- the preview for the invisible layer changes when you convert the floating selection into a new layer. That isn't supposed to happen, is it?
No that's correct. The preview shows the composite of the drawable and the floating selection -- until you click "new" to separate them. There is however a bug when undoing the "new" operation. The FS is not re-composited with the drawable.
Well then, I think the cause of the bug this report is about is that the mode conversion code is calculating its color map using the composited layer rather than taking into account both the floating selection and the underlying layer -- because it builds a histogram of colors by walking through the layer list and somehow misses the underlying layer in the process.
Bingo. You tracked it down. Colorspace conversion is about the only place where we need to rigor/relax the FS before/after the *image* is changed, not the drawable.
Fixed in both branches: 2005-02-02 Michael Natterer <mitch@gimp.org> * app/core/gimpimage-convert.c (gimp_image_convert): relax/rigor the floating selection around the convert operations so color analysis for indexed conversion works on the floating selection's drawable original pixels, and not on the composited one. Fixes bug #165342.
*** Bug 300203 has been marked as a duplicate of this bug. ***