Forget to say, it seems to behavior a little normal on 2.83 beta. it does not crash, but weird preview might occur. (Hope the information is enough)

Hey,I made a simple project now. so here I uploaded 2 file, the test.zip contains the test images in 1K reso. After unzip it, you might want to update the image texture node in material, and variable image_dir in script, it just reload the image from disk. After you run the script, simply check to Toggle Option, then redo/undo (just play around), it should crash. I also got a video with 3 times crashing.

Better file with relative paths and textures in one zip.

• Open file.
• Run the script in the scripting area.
• Click multiple time on the new Toggle button in the Viewport sidef panel.
• Undo until you can see the texture change.

The issue comes from the UNDO system that seems to shuffle the Image Textures. (the data does not correspond to the original data but they seem intact)

This affects GPUTexture but also the imbuf since it affects the UVImage editor (which does not use GPUTextures).

This also comes with a memory leak with GPUTextures not freed. I could not locate where/why this happens.

@Bastien Montagne (mont29) I'll leave it to you.

Cannot really reproduce this, besides a few memleaks that happen once in a while... Will double check how we deal with runtime gputexture thing, but besides that I cannot do much here unless I can reproduce it.

OK, so spent some more time investigating things and trying to understand what happens, with little success since I cannot even reliably reproduce any issue. But I think we might face one or both of following issues while trying to re-use runtime caches:

1. race condition.
2. pointer collisions across undo steps.

Not sure how #1 could happen, since both cache freeing and re-generation on-demand from draw code should happen in main thread, i.e. in a consistent order?
#2 Is also quiet difficult to follow, but since issue happen after repetitive cache freeing (triggered by the reload() RNA code): different caches being re-allocated at the same memory address as another one from a previous undo step.

But before losing more time on that wild goose chase, I'd like to hear from @Brecht Van Lommel (brecht) about that radical solution: since with new undo we re-use fully unchanged datablocks, can't we simply get fully rid of those imamap, movieclipmap, etc. ? Yes, it means that in some cases we'd regenerate the caches when it would not be needed, but I would not expect many changes to image of movieclip IDs to not require a cache reload anyway? And it would seriously simply code in readfile.c. Because right now we end up with some kind of double layer of remapping, makes things really hard to follow...

We can't get rid of imamap and similar. This is not only a cache, texture painted images and render results must be preserved.

Then am moving this to known issues, as this is for sure going to be a huge pain to fully understand and fix, and might very well require a complete redesign of how we preserve those caches (as a reminder, we had to add the session uuid thing ti IDs to precisely address that pointer collision issue...).