Visual glitches when undo after reload multiple images by script (in Material Preview) #76989

New Issue

xVanTuring · 2020-05-23T12:20:09+02:00

xVanTuring commented

2020-05-23 12:20:09 +02:00

System Information
Operating system: Windows 10 1909
Graphics card: Radeon RX 570

Blender Version
Broken: 2.90.0 Alpha, branch: arcpatch-D7884, commit date: 2020-06-15 14:16, hash: 81fcf23d7c
Worked: Probably never, 2.82 and earlier will crash, but that may be different bug.

Short description of error
So I'm currently making an add-on to support Substance, it will generate texture based on inputs and save them to disk, it will also generate material and assign texture generated before.
However on Version 2.82a with Material Preview mode after update a property, the add-on generate the texture, and auto reload the images, the press ctrl+z, normally it would undo the property, but it either crashs directly with EXCEPTION_ACCESS_VIOLATION, or ends up with a weird 3d preview. (below it's the normal one)

The weird thing is that it doesn't crash(2.82) if I run blender with blender_debug_log.cmd

Exact steps for others to reproduce the error
#76989.blend

Open File
Run script
In 3D viewport side panel click on Toggle option and undo
Repeat until you see glitch in material

**System Information** Operating system: Windows 10 1909 Graphics card: Radeon RX 570 **Blender Version** Broken: 2.90.0 Alpha, branch: arcpatch-[D7884](https://archive.blender.org/developer/D7884), commit date: 2020-06-15 14:16, hash: `81fcf23d7c` Worked: Probably never, 2.82 and earlier will crash, but that may be different bug. **Short description of error** So I'm currently making an add-on to support `Substance`, it will generate texture based on inputs and save them to disk, it will also generate material and assign texture generated before. However on Version 2.82a with Material Preview mode after update a property, the add-on generate the texture, and auto reload the images, the press `ctrl+z`, normally it would undo the property, but it either crashs directly with `EXCEPTION_ACCESS_VIOLATION`, or ends up with a weird 3d preview. (below it's the normal one) ![4.jpg](https://archive.blender.org/developer/F8549154/4.jpg) ![5.jpg](https://archive.blender.org/developer/F8549157/5.jpg) The weird thing is that it doesn't crash(2.82) if I run blender with `blender_debug_log.cmd` **Exact steps for others to reproduce the error** [#76989.blend](https://archive.blender.org/developer/F8622378/T76989.blend) - Open File - Run script - In 3D viewport side panel click on Toggle option and undo - Repeat until you see glitch in material

xVanTuring commented

2020-05-23 12:20:09 +02:00

Added subscriber: @xVanTuring

xVanTuring commented

2020-05-23 12:22:27 +02:00

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)

Richard Antalik commented

2020-05-25 13:37:55 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-05-25 13:37:56 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2020-05-25 13:37:56 +02:00

The description of this report is quite vague.

Can you prepare a simple script in .blend file that you can run and undo that would cause crash? Goal is to minimize time it takes to confirm bug as well as for developer to debug and fix the issue.

The description of this report is quite vague. Can you prepare a simple script in .blend file that you can run and undo that would cause crash? Goal is to minimize time it takes to confirm bug as well as for developer to debug and fix the issue.

xVanTuring commented

2020-05-25 22:57:19 +02:00

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. 2020-05-26 04-46-23.mkv

test.zip
dev13.blend

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. [2020-05-26 04-46-23.mkv](https://archive.blender.org/developer/F8553991/2020-05-26_04-46-23.mkv) [test.zip](https://archive.blender.org/developer/F8553982/test.zip) [dev13.blend](https://archive.blender.org/developer/F8553988/dev13.blend)

Campbell Barton commented

2020-06-10 05:04:19 +02:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Richard Antalik changed title from ~~Blender 2.82a crash randomly when undo after reload multiple images by script (in Material Preview)~~ to Visual glitches when undo after reload multiple images by script (in Material Preview)

2020-06-15 21:07:36 +02:00

Richard Antalik commented

2020-06-15 21:07:36 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Clément Foucault commented

2020-06-30 19:28:23 +02:00

Added subscribers: @mont29, @fclem

Clément Foucault commented

2020-06-30 19:28:23 +02:00

Better file with relative paths and textures in one zip.
#76989.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.

@mont29 I'll leave it to you.

Better file with relative paths and textures in one zip. [#76989.zip](https://archive.blender.org/developer/F8655530/T76989.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. @mont29 I'll leave it to you.

Bastien Montagne commented

2020-07-01 14:40:58 +02:00

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.

Bastien Montagne commented

2020-07-01 16:22:12 +02:00

Added subscriber: @brecht

Bastien Montagne commented

2020-07-01 16:22:12 +02:00

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:

race condition.
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 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...

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: - race condition. - 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 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...

Brecht Van Lommel commented

2020-07-01 16:40:02 +02:00

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

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

Bastien Montagne commented

2020-07-01 17:20:37 +02:00

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...).

blender-admin commented

2020-07-03 12:34:20 +02:00

This issue was referenced by 8e0f8bb3e1

This issue was referenced by 8e0f8bb3e153d5cae0050ceb90e6b561069fe05b

Bastien Montagne commented

2020-07-03 12:57:09 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue

2020-07-03 12:57:09 +02:00

Bastien Montagne self-assigned this 2020-07-03 12:57:09 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Visual glitches when undo after reload multiple images by script (in Material Preview) #76989

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.

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.