GIMP Version: 2.8.14
Operating System: Windows
GIMP Experience: Basic Level

---

Hi,
I'm not sure whether I did something wrong or if the case is as such:
- if I create inside a script a gradient -just to be used for that script- I cannot delete it at the end of the script if I intend (in the same Gimp session) use again that script (Gimp abends).
Which means -if this is true- that I have to perform the deletion of all the gradients (one per run) created by that script only after a Gimp close.
Is this correct?

Graechan,
that is what I tried, but I got a gimp crash when reusing (immediately after) the same script

I attach here the screenshot (sorry, the error window is in Italian)

addendum:
after the crash, I looked into the Gradients folder of Gimp, and none is there
(which confirms the first one created was deleted)

additional info (if somebody likes to know...)

I created a copy of my ongoing script in order to:
- reduce the code to the "essential" steps to reproduce the flow
- introduce many "gimp-message" to trace the steps

Using this test-version of the script I could assess that the crash occurs when my script (re-run after the first time, which runs correctly) calls the plug-in to create the gradient
(python-fu-palette-to-gradient-repeating 1 temp-palette)

The crash occurs ONLY if the first run of the script performs at its end the delete gradient, everything OK (even re-running my scripts ten times) if I comment out that stmt.

And you're hiding your code why?

are you referring to the whole script?
or to specific parts/statements I use?

@Dinasset
I think what Saul meant is: why don't you show us your test code so that we can try to reproduce the problem without having to guess what you're doing and then typing it in ourselves! And I agree.

Anyway, there doesn't seem to be a problem when invoked repeatedly from the Script-Fu Console:


Perhaps you could try a similar test exercise on the Script-Fu Console.

OK, here is the reduced script I created for testing the specific problem (it performs the complete flow -creation of a frame with colours derived from the picture-, I just took away additional code -under test- for managing parameters flexibility- for the test are irrelevant because this version shows the problem -my problem, on my PC, maybe not common...)

Okay, looks like a genuine problem.
I ran the script 3 times successfully on the same input image, but when I then ran it on a different image, Gimp crashed.

On my PC it crashes even if I repeat my script on the same image...

Yes, it seems to be related to the number of layers in the images.
You can run repeatedly with single-layer images (eg. open a PNG file, run the script, open another PNG, run the script, etc), but if you then open an XCF with multiple layers and run the script, GIMP crashes.

Also, starting Gimp from a console, I get these error messages on the console:


The gimp_image_undo_thaw error is because you're freezing the WorkImage, but then trying to Thaw the inImage:

But even after correcting that, Gimp still crashes with the gimp_wire_read() error.

thanks, corrected the mistake...

...but as you said, the Gimp crashes as well

by jontait2

A couple of things that are most likely unrelated to your problem.

First, your script is modifying the user's context. The python plug-in that creates the gradient also sets the default gradient. Then when you later delete the created gradient, the default gradient gets set to the first gradient in the gradient list, "FG to BG (HSV clockwise hue)". The user's original choice of default gradient is lost. Similarly the default palette gets set to the one you create.

Second, I would recommend disabling the undo history on your work image until your script is done. Since it is a new image created by your script, performing an undo after executing your script would only "reset" the work image to an empty state, not particularly useful for anybody. This would also allow you to remove freezing and thawing statements around the 'python-fu-wrap-map-bucket' call.

It is possible that the problem lies with the freezing of the undo history, if the wrap-map-bucket call modifies the work image. It is not actually defined what happens when an image changes while undo is frozen, but you are advised against it.

Try disabling the work image undo (and eliminating the freeze/thaw) and see if you still encounter the problem. While it is not likely to be the cause, it is easy to check.

EDIT: I failed to notice that the image being frozen was different than the image being thawed. Nonetheless, I still recommend eliminating the freeze/thaw altogether.

thanks!
commented out the four statement related to the WorkImage (no undo history at all)
as you expected, Gimp crashes as well...

WOW! the push/pop mechanism solved the problem!
thanks a lot!

one question, please:
about the WorkImage is it enough to have commented out all the four statements about undo history, or do I have to set explicitely a command to "disable" the undo history?

edit: I inserted the "disable" stmt immediately after the creation and the "enable" immediately before the disply-new

hope it's correct