save_as_mainfile will crash if context has no screen #93949

New Issue

Bay Raitt · 2021-12-10T21:52:08+01:00

Bay Raitt commented

2021-12-10 21:52:08 +01:00

System Information
Windows 10
GTX 970

Blender Version
Broken: 3.0
Worked: 2.93

Short description of error
using python, loading a template.blend file and saving as a new.blend file will crash blender if a camera is present in the template.blend file.

Exact steps for others to reproduce the error
In script editor execute:

import bpy
bpy.ops.wm.read_homefile()
bpy.ops.wm.save_as_mainfile(filepath='/tmp/test.blend')

With factory startup file, this will cause crash - NULL dereference in BKE_screen_find_big_area(), screen was NULL

**System Information** Windows 10 GTX 970 **Blender Version** Broken: 3.0 Worked: 2.93 **Short description of error** using python, loading a template.blend file and saving as a new.blend file will crash blender if a camera is present in the template.blend file. **Exact steps for others to reproduce the error** In script editor execute: ``` import bpy bpy.ops.wm.read_homefile() bpy.ops.wm.save_as_mainfile(filepath='/tmp/test.blend') ``` With factory startup file, this will cause crash - NULL dereference in `BKE_screen_find_big_area()`, `screen` was `NULL`

Bay Raitt commented

2021-12-10 21:52:08 +01:00

Added subscriber: @spiraloid-3

blender-admin commented

2021-12-10 21:52:08 +01:00

#95188 was marked as duplicate of this issue

blender-admin commented

2021-12-10 21:52:08 +01:00

#93950 was marked as duplicate of this issue

Richard Antalik commented

2021-12-10 22:06:42 +01:00

Added subscriber: @iss

Richard Antalik commented

2021-12-10 22:06:42 +01:00

Not sure if this is different report than #93950, but if there are different steps, please provide them.

Bay Raitt commented

2021-12-11 06:21:05 +01:00

Different issue then #93950.

(see last comment)

Steps to reproduce, Install the addon attached to my previous post and click “crash me” in the file menu.

or

write a python script to load a blend file containing a camera and then save out a new blend file.

this is essentially all my addon does.

if you look at my python, I commented the source of the crash. (it has something to do with loading a .blend file containing a camera and saving again)

I spent quite a bit of time finding the exact steps to reproduce this crash.

Different issue then #93950. (see last comment) Steps to reproduce, Install the addon attached to my previous post and click “crash me” in the file menu. - or write a python script to load a blend file containing a camera and then save out a new blend file. this is essentially all my addon does. if you look at my python, I commented the source of the crash. (it has something to do with loading a .blend file containing a camera and saving again) I spent quite a bit of time finding the exact steps to reproduce this crash.

Michael commented

2021-12-11 08:51:37 +01:00

Added subscriber: @michael64

Michael commented

2021-12-11 08:51:37 +01:00

Thanks @spiraloid-3 for the detailed description, I could reproduce the crash, find a fix for future Blender versions and a workaround for you to get your add-on working with Blender 3.0.

For your workaround you have to circumvent the automatic thumbnail generation that was introduced in 4fa0bbb5.
This can be done for example like this

        # :::::::::::::::::::::::::::::::::::::::::::::::::::Avoid Trigger Crash here 
        if bpy.context.screen is not None:
            bpy.ops.wm.save_as_mainfile(filepath=clean_target_filename)
        else:
            - Prevent crash when the context has no screen
            - by temporarily disabling automatic thumbnail generation.
            old_preview_type = bpy.context.preferences.filepaths.file_preview_type
            bpy.context.preferences.filepaths.file_preview_type = 'NONE'
            try:
                bpy.ops.wm.save_as_mainfile(filepath=clean_target_filename)
            finally:
                # Restore file_preview_type
                bpy.context.preferences.filepaths.file_preview_type = old_preview_type
        # :::::::::::::::::::::::::::::::::::::::::::::::::::Avoid Trigger Crash here

Because thumbnails are only automatically generated from the main thread, calling bpy.ops.wm.save_as_mainfile from another thread should also work but the previous workaround seems simpler.
Also if the scene already had a thumbnail it would not be regenerated in save_as_mainfile.

Now for the cause of the crash for the Blender developers.
The automatic thumbnail generation calls BKE_screen_find_big_area in wm_files.c: (BKE_screen_find_big_area(CTX_wm_screen(C), SPACE_VIEW3D, 0) != NULL)
This function in screen.c references screen->areabase before checking if screen is NULL which can be the case when called from a Python add-on.
This dereferencing screen->areabase crashes the Blender process.

I would propose a three-line addition that returns NULL if a NULL screen was passed in as the logic that NULL can be returned seems to be already expected by the callers:

ScrArea *BKE_screen_find_big_area(bScreen *screen, const int spacetype, const short min)
{
  ScrArea *big = NULL;
  int maxsize = 0;
  if (screen == NULL) {
    return NULL;
  }

I have not looked at the difference to #93950 but maybe the same error could be triggered in two different ways.

        bool do_render = (scene != NULL && scene->camera != NULL &&
                          (BKE_screen_find_big_area(CTX_wm_screen(C), SPACE_VIEW3D, 0) != NULL));

That scene->camera != NULL short circuits the call to BKE_screen_find_big_area in case of a missing camera also explains why crashmenot.blend does not crash.

Thanks @spiraloid-3 for the detailed description, I could reproduce the crash, find a fix for future Blender versions and a workaround for you to get your add-on working with Blender 3.0. For your workaround you have to circumvent the automatic thumbnail generation that was introduced in 4fa0bbb5. This can be done for example like this ``` # :::::::::::::::::::::::::::::::::::::::::::::::::::Avoid Trigger Crash here if bpy.context.screen is not None: bpy.ops.wm.save_as_mainfile(filepath=clean_target_filename) else: - Prevent crash when the context has no screen - by temporarily disabling automatic thumbnail generation. old_preview_type = bpy.context.preferences.filepaths.file_preview_type bpy.context.preferences.filepaths.file_preview_type = 'NONE' try: bpy.ops.wm.save_as_mainfile(filepath=clean_target_filename) finally: # Restore file_preview_type bpy.context.preferences.filepaths.file_preview_type = old_preview_type # :::::::::::::::::::::::::::::::::::::::::::::::::::Avoid Trigger Crash here ``` Because thumbnails are only automatically generated from the main thread, calling bpy.ops.wm.save_as_mainfile from another thread should also work but the previous workaround seems simpler. Also if the scene already had a thumbnail it would not be regenerated in save_as_mainfile. Now for the cause of the crash for the Blender developers. The automatic thumbnail generation calls BKE_screen_find_big_area in wm_files.c: (BKE_screen_find_big_area(CTX_wm_screen(C), SPACE_VIEW3D, 0) != NULL) This function in screen.c references screen->areabase before checking if screen is NULL which can be the case when called from a Python add-on. This dereferencing screen->areabase crashes the Blender process. I would propose a three-line addition that returns NULL if a NULL screen was passed in as the logic that NULL can be returned seems to be already expected by the callers: ``` ScrArea *BKE_screen_find_big_area(bScreen *screen, const int spacetype, const short min) { ScrArea *big = NULL; int maxsize = 0; if (screen == NULL) { return NULL; } ``` I have not looked at the difference to #93950 but maybe the same error could be triggered in two different ways. ``` bool do_render = (scene != NULL && scene->camera != NULL && (BKE_screen_find_big_area(CTX_wm_screen(C), SPACE_VIEW3D, 0) != NULL)); ``` That scene->camera != NULL short circuits the call to BKE_screen_find_big_area in case of a missing camera also explains why crashmenot.blend does not crash.

Bay Raitt commented

2021-12-12 05:37:18 +01:00

Thanks so much @michael64, Much appreciated.