Confirmed! If I modify the script to allow the bpy.ops.wm.save_as_mainfile operator to be called from a button located within a sub panel in the render properties area of the Blender UI, I can't crash blender no matter how hard I try. So it seems the popup handler is somehow freeing the UI list incorrectly?! The UI list is instantiated in the panel, not the popup so could maybe @Robert Guetzkow (rjg) let us know why this is happening? I would imagine it makes sense to free the popup, but not the UI_List from which the button was pressed to generate the popup! Its still supposed to be there after the popup is gone!

this is the call stack right after clicking the button, it calls free, then afterwards ui_list_ensure accesses that freed memory

Looks like the pop-up handler is incorrectly freeing the template list? The preceding stack frames show some operations related to a "popup" which I assume to be the props dialog that we use (both in our addon and I included it in the minimal test case script).

If redrawing the UI crashes, then you can also get a crash if the user does anything in the UI, not just a script.

I really would like to see a backtrace or some investigating of the crash before accepting a workaround.

cool, I'd opt for the fix where feasible, but reproducing the error is somewhat of a trial and error process. So it would definitely take longer. I am also surprised it hasn't been raised by anyone else yet. I guess our addon (which uses save_as_mainfile much the same as others, included those bundled with Blender) is just 'lucky'.

Hi @William Leeson (leesonw) 😄 just checking in to see if there's anything else I can help with here? I've noticed we're close to getting this patch in, which is great. If there's something you need please let me know!

Thanks @Campbell Barton (campbellbarton) & @Brecht Van Lommel (brecht) 😄 appreciate the help on getting this patch in.

Looks Good to me?? I think only the title changed, which is a fair enough change. Brevity was never my strong suit.

@Campbell Barton (campbellbarton) I tried, and I failed, urhghghg 😵 .

Guess I may as well claim this? I mean, I have created a differential for it now so I think that makes me the person responsible for it xD.

@Bay Raitt (spiraloid) Welcome :) Are you at all able to contribute by submitting a minimum test case for your particular situation? happy to test that on my patch to make sure it actually fixes your case as well :)

@Brecht Van Lommel (brecht) Patch is incoming, I am getting my dev env setup, I was using the GitHub mirror, but after reading the guidelines on the wiki for blender development, seems you guys prefer arcanist? I just installed php and am working on installing arcanist tonight, then hopefully I'll be able to get setup for dev again using the official blender repository rather than the GitHub mirror.

@Brecht Van Lommel (brecht), @Campbell Barton (campbellbarton) ok, I've reverted the change in my branch and implemented the suggestion to use if (BLI_thread_is_main()). The testing was a success with no more crashes and the thumbnails/screenshots taken when pressing save do not contain open menus in them, so I think I'll be submitting a branch with these changes as a patch for to close this issue, so long as it passes the review process :P

@Brecht Van Lommel (brecht) I'll make those changes in my branch and report back. Happy to submit a patch like that if it fixes the crash and D12507 still has its intended effect.

@Campbell Barton (campbellbarton) Yeah, thats def on me :( apologies, I missed the fact I had references to our addon in that script. I will fix and re-post the script to remove references to our addon.

ok final tests confirmed that I can move the call to redraw to the wm_save_as_mainfile_invoke in wm_files.c.

@Brecht Van Lommel (brecht) Finally tracked down the issue and commit that introduced the bug! This issue was caused by a change back in September 17th. https://developer.blender.org/D12507 was created to deal with the following...

Further testing done, I checked the latest python API spec for the bpy.ops.wm.save_as_mainfile operator. Check existing is set to true to warn if the file already exists. To eliminate this as a potential issue I tested setting this to False in my code. Sadly this still causes an instant crash on Windows so this seems to not help.

Update, have done more testing and its also broken on MacOS as well. Haven't tested linux yet though.

Just updated the attached addon so it has the @persistent decorator. Looks like I moved the file when I was testing it with Blender 3.0.0 and then uploaded the copy from the old location. I have edited the task above and replaced the addon with the one I was able to reproduce the same crash with.

In T92258#1236621, @Erik Abrahamsson (erik85) wrote:

I tried this on Win10 but can't reproduce the crash. I also had to modify the script with from bpy.app.handlers import persistent and @persistent decorator on the handler function to make it run.

Keen to help out with testing this, especially for mac users who currently have no ability to use AMD GPUs since the removal of support for openCL. Would appreciate being directed to where the source can be cloned and any special build instructions and will test on a mac-AMD RX5700XT platform.

Re question on devtalk, would like to know if resumable chunk rendering is being removed? If it is, will there be a replacement?

In T82384#1062836, @Bastien Montagne (mont29) wrote:

I got the mail... Yours might have ended up in spams? Got closed by the fixing commit.

Weird, just checked this issue and can see its closed, but didn't get an update via e-mail, is that expected? I got the initial one about the issue being created!

@Bastien Montagne (mont29) @Robert Guetzkow (rjg) @Philipp Oeser (lichtwerk) Thanks guys :) Really appreciate you guys looking into this. Willing to test this as soon as its in a daily build if that will help.

thanks @Brecht Van Lommel (brecht) :D

In T66754#720579, @ken wong (ken) wrote:

mac osx mojave

new blender 2.8 blender-2.80rc1-macOS fixed the missing Toolbar And cycle.

but some addon like machin3tool / fluid / etc. addon , got issue when active in preference.

delete >>> application support /blender/ blender 2.80 folder
re download the 2.8 RC1 again ,
preference active got issue

@Campbell Barton (campbellbarton) Thank you :), just downloaded the latest 2.80 beta directly from blender.org and so far, all working well. Thanks again. Can't overstate how grateful we are.... and relieved too. :)

Pasting the code given in this post into blender's (blender 2.80.40) script editor and hitting the run script button gives me this output:

In T60934#614228, @Campbell Barton (campbellbarton) wrote:

Hi @Bastian Neumann (bneu), this is mostly a question of priorities since there are enough high priority undo bugs open which need attention, see: T61045

2.79b also didn't properly initialize undo, eg: wm_files.c

	if (!G.background) {
		BKE_undo_reset();
		BKE_undo_write(C, "original");  /* save current state */
	}

While it didn't crash, it wasn't fully working either.

This is something to look into, if we should have basic memfile undo support in background mode, or add the ability to fully initialize undo.

Some context for how you're using this feature in 2.79 would be helpful.

---

I commented about this on the thread that explained how to use it, but no one ever replied to my comment that it wasn't working.

Could you link to this post?

@Jeducious (jameshcrowther), can you briefly explain what you need undo in background mode for? For memory usage on render nodes being able to save memory is quite important, and now might be a good time to make such a breaking change. However there may be solutions to handle both cases.

Note that there is a replacement for scene_update_post in the form of depsgraph_update_post and the new timer API.

@Campbell Barton (campbellbarton) I can appreciate the reasoning you gave for not reinstating the undo stack in background mode. However, I respectfully request you reconsider. For one, the change that we're talking about was never mentioned in the API changes for 2.80. Yet you mentioned it is an intentional change. That change has now given us a major redesign task to make our addon compatible with 2.80 that we were not expecting and it would be fantastic to have more time to adjust. Given time we can work around.

@Brecht Van Lommel (brecht) @Philipp Oeser (lichtwerk) @Campbell Barton (campbellbarton) Thanks guys :)

In T57069#589070, @Jonathan Forby (forby) wrote:

I had the same issue, and realized that I usually work with my display resolution (MacOS Settings > Display) set to scaled for more space. This seemed to work for me:

• Change display resolution back to Default for display
• Back in Blender, reload the startup file and save it (may be optional if it's just one setting, but worked for me)
• Can now change the display resolution back to scaled, and the effect doesn't reappear.

I do notice that after the fix blender still won't start at full window size. It starts down in the corner like before, but without the frame stretched and mouse inputs off. So at least it's usable.

Hope this helps!

Ok, I have solved the issue on my MacBook pro 2015 model by starting blender (version 2.80.39) with the option --no-native-pixels. The ui is now fully filling the window its rendered in and the mouse pointer is no longer rendered offset from its position as given by the events system. But the display is butt ugly, no more retina resolution for me. Its rendering at a lower resolution now. At least it is usable, but I don't like how it looks now. So I'd say we should still keep this issue open, esp since its not immediately obvious to the average mac user (feel like I should include myself in that category by the way) that the no native pixels setting is the answer to this problem.

Hi @Brecht Van Lommel (brecht), I've updated the details of the report as per the URL you gave :)

Curiously enough just discovered that this problem doesn't exist in the preferences window. The scaling and mouse pointer are all aligned properly if I open the user preferences, but remain incorrectly scaled in the main ui

I have this issue on the following system ( laptop, macbook pro 2015 ->

Hi all and of course @Brecht Van Lommel (brecht) :) , Ok, so this issue is closed but, wanted to add my comments since as of the 27th of November I still have an issue with screen scaling. On macOS Mojave (see

YES PLEASE FOR A NEW CALLBACK! I'll add some further context to my desire to upvote this proposal. I am currently in the category of having to use 'loop kicking' (interesting term for it, but its what we have to do). We need to be able to run an event loop to capture msgs to our distributed rendering platform for blender. Msgs come back to blender from other nodes, currently we've had to use a modal operator with a timer to implement async operations. I got excited about asyncio a while back, but realised that it needed to have the same modal operator to work. If there was an event that could be subscribed to that would avoid the need to have a modal operator running this would be excellent. Modal operators when used for look kicking have some pretty undesirable drawbacks;

Hi Brecht,

First, thanks so much for the fast reply, I've been testing as you suggested and with the depth pass connected to the Z socket this works as you said it should. However, there is no mention of this fact in the documentation and I think it would save others a lot of head scratching if the docs simply announced what you wrote above.

The problem is compounded by the fact that the vector blur seems to work without the z pass connected, that coupled with no explanation of if in the docs meant it wasn't obvious that the Z input was the issue. So I've set the status to open, hope the documentation edit will help others not fall over their feet like I did :)

@Campbell Barton (campbellbarton) Hi! When I try running the above code as a script from the text editor in blender, I get this error in the system console:

@Lukas Stockner (lukasstockner97)
Hey there, hope you had a great Christmas and and are so far having a happy new year. I was very interested to see something finally happening with cycles network rendering. However, I'd like to also point out that we're already distributing a free addon that provides distributed rendering for cycles, works in AWS and works P2P. It is also cross platform out of the box. It even distribute the denoising pass so that all nodes do denoising on their own image tiles. We have a small online following, but it is growing.

Hi guys, and particularly @Campbell Barton (campbellbarton), @Sergey Sharybin (sergey) :D merry Christmas to you and the blender devs team :)

@Brian Cary (brinux) We're working on an addon to fix this, anticipate that the fix will be integrated into our addon end of June this year. Feel free to contact us if you'd like to test. We got snagged on this problem too but found there is a way round it, but it involves programming, so we're building this into our addon which does network rendering.

@Campbell Barton (campbellbarton) , different issue - no problem. Just seemed close enough to warrant re-opening this one rather than creating a whole new bug report.

Hi guys, using current release (see system info here->

I think there is sufficient information in the blender api, though I think the issue here is that the scene_handler_pre handler does something that is not expected by triggering constantly.

@Campbell Barton (campbellbarton) I like the approach of not adding this into 2.8 so we can find a way around this, more time would really be appreciated so we can perhaps work together to find a more acceptable way forward :D.

Hi, my comment regards the propsed changes to the scene_update_pre handler. To some extent I'm echoing Brendon's concerns - (repeated below).

Hi Joey, can you elaborate on "better options" Im working on a network rendering addon for blender at the moment, would be nice to know what the plans are regarding this feature.

Hi Arnaud, have been looking through this code, but not sure what you meant by your last comment. I am new to the blender cpp code. I did find this

Hi Arnaud, :D

Thanks for your comment. That is an important point. We've been wondering for a while how to get around the issue, here is what we're facing right now, it is as you described.

Still present in 2.78a , I guess this is not going away? We've encountered it whilst developing a network render addon similar to Netrender, except we do bucket rendering or frame splitting. For us, the ability read in a multilayer exr is rather critical since the work around by Arnoud above doesn;t work for us.