Thank you, Sergey - it's understandable. May I ask how the viewport (during gui rendering) getting the picture? Maybe there is a way to get it out of GPU on demand, like by calling _cycles.draw()?

Hmmm, I understand that it's not supported officially (as a declared feature) - but the API allows to do that and worked before v3 just well. If you will run it with previous version of blender (like I did with 2.93.1 for example) - you will see that the png is actually is quite here:

> BLENDER_USER_CONFIG=. BLENDER_USER_SCRIPTS=. ~/local/blender-2.93.1-linux-x64/blender -b -noaudio --python-expr "
import bpy
bpy.context.scene.render.engine = 'CYCLES'
bpy.context.scene.render.image_settings.file_format = 'PNG'
bpy.context.scene.cycles.use_adaptive_sampling = False
bpy.context.scene.cycles.samples = 2048
bpy.context.scene.cycles.use_progressive_refine = True
counter=0
def my_handler(scene):
    global counter; counter += 1
    if counter  < 60:
        return
    print('\ntaking screenshot\n')
    bpy.data.images['Render Result'].save_render('_preview.png')
    print('screenshot taken\n');
    import sys;
    sys.exit(0)
bpy.app.handlers.render_stats.append(my_handler)

Ok, just found a better (slightly) way to reproduce - don't know a way to get and parse status using built-in python, but simple if counter < 38 makes it happen right in time of printing the second sample status:

Oh sorry about that, I have a relatively powerful workstation (48 threads 128GB RAM) - so now can't be sure it is able to be reproduced this way (even though I'm running my distributed agents in docker containers with 4 threads and 4GB of ram and there I'm able to reproduce it constantly, maybe it's up to CPU features or something)... For example on a much slower speed it could not get the memory corruption if will save exr before the buffers will change or something... You can try to run the save_render manually without this sleep or let me try to test it again with handler like bpy.app.handlers.render_stats because my preview saving is actually triggered during that event.

Any updates? Do you think it's possible to include in 2.93 LTS release?

Hi @Philipp Oeser (lichtwerk) , no, this issue is about Cycles merger (built-in cycles functionality https://github.com/blender/blender/blob/master/intern/cycles/blender/addon/operators.py#L160 ), I just use a simple script from my addon to run and test it.

@Robert Guetzkow (rjg) I understand the complexity of catching every issue possible - it's not a great for sure. But if the error generates the message where instead of the module directory "BlendNet-v0.3.3" we have part of it "BlendNet-v0" - it looks weird. For sure it's a limitation of the python, but who need to be aware of it and find out what's wrong - Blender or the User?

@Robert Guetzkow (rjg) I totally agree that addon developers should test their code and make sure it's working well - that's why BlendNet is used daily CI to ensure that the addon is working properly on 2.80, LTS and Latest Blender. And right now there is no issue in the addon itself, it's just the GitHub interface that posting additional files on the release page:

So for example in my particular case - I did everything correctly, packed my great addon properly, but github also provides a way to download the sources of the release and the tags are attached to the repo name like "BlendNet-v0.5" (https://github.com/state-of-the-art/BlendNet/issues/123#issuecomment-734960407). It's a different convo with github guys here: https://github.community/t/control-prefix-of-the-release-source-code/145808 , but overall there is not much I can do if user by mistake clicks on this link and downloads the wrong artifact. Or even just to accidentally put dot in the name because he likes dots - doesn't matter.

Unfortunately no - the users installs the addon archive, see the exception and don't understand why it's not found. It's not obvious - the addon is here (folder and stuff), but just contains dot in the name.

Ok, during preparing of the example bundle I found what was the actual issue - seems like if the current scene render engine changes from the render engine - it's causing the crash.

Hi @Richard Antalik (ISS) , sure will prepare a simple test suite to check the behavior.

Just found another thing with baking on 2.90 - if I'm changing the initial fuel level (0-1.3 bezier) for example and not starting from 1.3 - it's dissolving before reaching top of the domain, than it probably will not fail. Not sure how it's related, but maybe it's a workaround for now - just make sure the fire particles not reaching the domain limits.

Hello Guys, just found quite the same during working on BlendNet addon (https://github.com/state-of-the-art/BlendNet/issues/57#issuecomment-687360342), it's not critical - but definitely will be great to have it fixed.

I just tested the latest blender-2.91.0-ba188e721899-linux64 build:

So, I checked recently released 2.90 - even worse it crashed on 2th step "baking" (5th domain bake, 215 frame):

$ blender
found bundled python: /home/user/local/blender-2.90.0-linux64/2.90/python
Read blend: /home/user/tmp/mantaflow/mantaflow-render-test.blend
terminate called after throwing an instance of 'Manta::Error'
  what():  can't clean grid cache, some grids are still in use
Error raised in /home/sources/buildbot-worker-linux_centos7/linux_290/blender.git/extern/mantaflow/preprocessed/fluidsolver.cpp:33
zsh: abort (core dumped)  blender

Hello Guys, anyone could reproduce? @Raimund Klink (Raimund58)

Simple test blend file:

Ok, just reproduced the issue on a simple blend file and default blender 2.83.5 . Will reproduce one more time from nothing and will attach the steps to reproduce and the file.

Looks like it's happening during animation rendering once per ~150 frames, still trying to figure out the minimal configuration.

So the change will be added only to 2.9? Do you have plans to integrate it to 2.83 LTS?

Yep, affecting me too. I think it's somehow related to the prefetch frames mechanism - when it's working on the erasing strip there are ~100% chance to crash.