Regression: Crash when saving after pressing ctrl+S twice. #88570

New Issue

Jacques Lucke · 2021-05-25T16:52:50+02:00

Jacques Lucke commented

2021-05-25 16:52:50 +02:00

System Information
Operating system: Linux-5.12.3-arch1-1-x86_64-with-glibc2.33 64 Bits
Graphics card: AMD Radeon RX 5700 (NAVI10, DRM 3.40.0, 5.12.3-arch1-1, LLVM 11.1.0) AMD 4.6 (Core Profile) Mesa 21.1.0

Blender Version
Broken: version: 2.92, 2.93.0 Beta (1a69d491e5), 3.0 Alpha (067587e329).
Worked: 2.83

Caused by 796412dca0

Short description of error
Blender crashes when I click on save in the file browser after pressing ctrl+S twice.

Exact steps for others to reproduce the error

Open default scene.
Press ctrl+S to open the save file dialog.
When it opened, press ctrl+S again.
Click on "Save Blender File".
Crash.

_BLI_assert_abort() (/home/jacques/blender-git/blender/source/blender/blenlib/intern/BLI_assert.c:56)
wm_handler_fileselect_do(bContext * C, ListBase * handlers, wmEventHandler_Op * handler, int val) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2316)
wm_handler_fileselect_call(bContext * C, ListBase * handlers, wmEventHandler_Op * handler, const wmEvent * event) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2462)
wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2906)
wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2958)
wm_event_do_handlers(bContext * C) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:3378)
WM_main(bContext * C) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm.c:647)
main(int argc, const char ** argv) (/home/jacques/blender-git/blender/source/creator/creator.c:520)

**System Information** Operating system: Linux-5.12.3-arch1-1-x86_64-with-glibc2.33 64 Bits Graphics card: AMD Radeon RX 5700 (NAVI10, DRM 3.40.0, 5.12.3-arch1-1, LLVM 11.1.0) AMD 4.6 (Core Profile) Mesa 21.1.0 **Blender Version** Broken: version: 2.92, 2.93.0 Beta (1a69d491e5), 3.0 Alpha (067587e329). Worked: 2.83 Caused by 796412dca0 **Short description of error** Blender crashes when I click on save in the file browser after pressing ctrl+S twice. **Exact steps for others to reproduce the error** 1. Open default scene. 2. Press ctrl+S to open the save file dialog. 3. When it opened, press ctrl+S again. 4. Click on "Save Blender File". 5. Crash. ``` _BLI_assert_abort() (/home/jacques/blender-git/blender/source/blender/blenlib/intern/BLI_assert.c:56) wm_handler_fileselect_do(bContext * C, ListBase * handlers, wmEventHandler_Op * handler, int val) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2316) wm_handler_fileselect_call(bContext * C, ListBase * handlers, wmEventHandler_Op * handler, const wmEvent * event) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2462) wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2906) wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:2958) wm_event_do_handlers(bContext * C) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:3378) WM_main(bContext * C) (/home/jacques/blender-git/blender/source/blender/windowmanager/intern/wm.c:647) main(int argc, const char ** argv) (/home/jacques/blender-git/blender/source/creator/creator.c:520) ```

Jacques Lucke commented

2021-05-25 16:52:50 +02:00

Added subscriber: @JacquesLucke

blender-admin commented

2021-05-25 16:52:50 +02:00

#96185 was marked as duplicate of this issue

blender-admin commented

2021-05-25 16:52:50 +02:00

#89683 was marked as duplicate of this issue

blender-admin commented

2021-05-25 16:52:50 +02:00

#89075 was marked as duplicate of this issue

Dalai Felinto commented

2021-05-25 17:06:03 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2021-05-25 17:06:03 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Dalai Felinto self-assigned this 2021-05-25 17:06:03 +02:00

Dalai Felinto commented

2021-05-25 17:06:03 +02:00

I can reproduce this in 2.92 as well as 2.93 and master. It doesn't happen in 2.91.

Raimund Klink commented

2021-05-25 23:56:22 +02:00

Added subscriber: @Raimund58

Raimund Klink commented

2021-05-25 23:56:22 +02:00

Blender 2.83.15 is also not affected (on Windows)

Harley Acheson commented

2021-05-26 01:48:09 +02:00

Added subscriber: @Harley

Harley Acheson commented

2021-05-26 01:48:09 +02:00

Actually I just got the exact same behavior in 2.91.0 (for Windows).

Dalai Felinto commented

2021-05-27 11:25:21 +02:00

Interesting, in Linux I cannot reproduce it in 2.91.

Garek commented

2021-05-27 12:18:00 +02:00

Added subscriber: @Garek

Garek commented

2021-05-27 12:18:00 +02:00

Can confirm on Windows for 2.90.
Working for 2.83.15 as well as 2.83.0

Can confirm on Windows for 2.90. Working for 2.83.15 as well as 2.83.0

Harley Acheson commented

2021-05-29 18:20:42 +02:00

@dfelinto - Interesting, in Linux I cannot reproduce it in 2.91.

Yeah, was doubting myself after seeing other people say otherwise. So I downloaded it again and gave it another try.

Date: 2020-11-25 08:34
Hash: 0f45cab862

And it definitely dies, just as described above. But there are further details that might help:

How quickly you press that second ctrl-S makes a big difference. Best to wait at least a second or two between them just to be sure.

This same issue occurs when pressing the "Cancel" Button on the same form. But NOT when clicking the "X" close in the titlebar. This could be a very interesting clue.

> @dfelinto - Interesting, in Linux I cannot reproduce it in 2.91. Yeah, was doubting myself after seeing other people say otherwise. So I [downloaded it again ](https://download.blender.org/release/Blender2.91/) and gave it another try. Date: 2020-11-25 08:34 Hash: 0f45cab862b8 And it **definitely dies**, *just as described above*. But there are further details that might help: How quickly you press that second ctrl-S makes a big difference. Best to wait at least a second or two between them just to be sure. This same issue occurs when pressing the "Cancel" Button on the same form. But NOT when clicking the "X" close in the titlebar. This could be a very interesting clue.

Ankit Meel commented

2021-06-13 07:44:09 +02:00

Added subscribers: @coolchou-zhao, @ankitm, @PratikPB2123

Ankit Meel commented

2021-06-13 07:45:55 +02:00

Also happens with:

command + O
command + S
Escape/ Enter to save.

Also happens with: - command + O - command + S - Escape/ Enter to save.

Robert Guetzkow commented

2021-07-06 13:49:44 +02:00

Added subscriber: @YKTMU2

Dalai Felinto was unassigned by Julian Eisel

2021-07-19 17:49:04 +02:00

Jake self-assigned this 2021-09-19 23:41:02 +02:00

Paul Kotelevets commented

2021-12-04 02:41:26 +01:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2021-12-04 02:41:26 +01:00

Saving action is more than an action - it is a reflex, a part of a CG survival instinct.
A way to save massively learned from the industry standards design solutions has its own memes:

In #88570#1168210, @Harley wrote:
How quickly you press that second ctrl-S makes a big difference. Best to wait at least a second or two between them just to be sure.

Not exactly, it looks like it more depends on if you press

full Ctrl+S several times
or Ctrl+SSSS way.
The second way seems to be stable.

Saving action is more than an action - it is a reflex, a part of a CG survival instinct. A way to save massively learned from the industry standards design solutions has its own memes: ![image.png](https://archive.blender.org/developer/F12688056/image.png) ![image.png](https://archive.blender.org/developer/F12688082/image.png) > In #88570#1168210, @Harley wrote: > How quickly you press that second ctrl-S makes a big difference. Best to wait at least a second or two between them just to be sure. Not exactly, it looks like it more depends on if you press - full Ctrl+S several times - or Ctrl+SSSS way. The second way seems to be stable.

Michael commented

2021-12-10 08:11:13 +01:00

Added subscriber: @michael64

Michael commented

2021-12-10 08:11:13 +01:00

The described crash happens as follows.
In the function GHOST_ScreenToClient the following line is executed:
window->screenToClient(inX, inY, *outX, *outY);
When window is NULL the process crashes but here we are in a code segment that we shouldn't have gotten into in the first place.

Reproducing this bug in a debug build with enabled asserts aborts the process earlier because of a failed assert in wm_event_system.c:

  BLI_assert(ctx_win != win);

So we have ctx_win == win which it shouldn't be but a release build with disabled asserts just marches on and crashes later.

Let's have a look at the big picture.
One could say that most powers users don't like modal dialogs in general. They are overused and annoying, especially when not needed.

As an example, we have a fresh scene with the default cube. Let's move the default cube to the left window border so it's still visible when we press Ctrl-S to save the scene.

Now we have the "Blender File View" save dialog open and the default cube next to the left of it.

Now pressing 'g' to move the default cube does not allow me to move the default cube which seems appropriate to me.
With the save dialog open, I can go to the Object Properties to adjust the x value of the location and click on the number which is in focus but the field does not accept key events, not even moving the cursor.
But I can still click and scrub location.x and see the cube moving while the save dialog is open. Should this even be possible? I don't know, it's a matter of taste I guess.

Likewise I can also press Ctrl-Shift-O to get the recent files dialog while the the save dialog is open. This could even make sense if one just wanted to be reminded of a recent file name before saving.

Back to the details in wm_event_system.c.
A quick workaround like this is not what we are looking for:

        if (BLI_listbase_is_single(&file_area->spacedata)) {
          if (ctx_win == win) {  // This would prevent an immediate
            continue;            // crash but still allows
          }                      // a weird app state.
          BLI_assert(ctx_win != win);

This would still allow a second file window(over the first one to be opened.
Cancelling the second window would remove it as well as the file name, Cancel and Save As buttons. Now the file dialog can only be closed by clicking the 'x'.
My intuition tells me that in this particular case it might be a good idea to not open the second file dialog instance while the first one is still opened.

That's my diagnosis, maybe somebody else knows how to prevent improperly nested file dialogs tastefully.

The described crash happens as follows. In the function GHOST_ScreenToClient the following line is executed: window->screenToClient(inX, inY, *outX, *outY); When window is NULL the process crashes but here we are in a code segment that we shouldn't have gotten into in the first place. Reproducing this bug in a debug build with enabled asserts aborts the process earlier because of a failed assert in wm_event_system.c: ``` BLI_assert(ctx_win != win); ``` So we have ctx_win == win which it shouldn't be but a release build with disabled asserts just marches on and crashes later. Let's have a look at the big picture. One could say that most powers users don't like modal dialogs in general. They are overused and annoying, especially when not needed. As an example, we have a fresh scene with the default cube. Let's move the default cube to the left window border so it's still visible when we press Ctrl-S to save the scene. Now we have the "Blender File View" save dialog open and the default cube next to the left of it. Now pressing 'g' to move the default cube does not allow me to move the default cube which seems appropriate to me. With the save dialog open, I can go to the Object Properties to adjust the x value of the location and click on the number which is in focus but the field does not accept key events, not even moving the cursor. But I can still click and scrub location.x and see the cube moving while the save dialog is open. Should this even be possible? I don't know, it's a matter of taste I guess. Likewise I can also press Ctrl-Shift-O to get the recent files dialog while the the save dialog is open. This could even make sense if one just wanted to be reminded of a recent file name before saving. Back to the details in wm_event_system.c. A quick workaround like this is not what we are looking for: ``` if (BLI_listbase_is_single(&file_area->spacedata)) { if (ctx_win == win) { // This would prevent an immediate continue; // crash but still allows } // a weird app state. BLI_assert(ctx_win != win); ``` This would still allow a second file window(over the first one to be opened. Cancelling the second window would remove it as well as the file name, Cancel and Save As buttons. Now the file dialog can only be closed by clicking the 'x'. My intuition tells me that in this particular case it might be a good idea to not open the second file dialog instance while the first one is still opened. That's my diagnosis, maybe somebody else knows how to prevent improperly nested file dialogs tastefully.

Paul Kotelevets commented

2021-12-10 12:52:03 +01:00

Previously a file dialog in Blender was opened fullscreen instead of a window (which was a nice solution to win 95 window file dialog style, still presented in industry standards - so you can work with long paths and view lots of data).
Does it influence?

Previously a file dialog in Blender was opened fullscreen instead of a window (which was a nice solution to win 95 window file dialog style, still presented in industry standards - so you can work with long paths and view lots of data). Does it influence?

Pratik Borhade commented

2022-02-23 13:42:23 +01:00

This report is not appearing in normal searches and crash wasn't fixed in 3.0.0 release. So setting back #bf_blender project

Pratik Borhade commented

2022-03-06 03:42:26 +01:00

Added subscriber: @PsychoFisch

Philipp Oeser commented

2022-03-25 14:09:19 +01:00

Added subscribers: @JulianEisel, @lichtwerk

Philipp Oeser commented

2022-03-25 14:09:19 +01:00

Caused by 796412dca0 btw.

@JulianEisel:I know you have a fix ready already, mind getting that reviewed/pushed somehow?

Caused by 796412dca0 btw. @JulianEisel:I know you have a fix ready already, mind getting that reviewed/pushed somehow?

Philipp Oeser changed title from ~~Crash when saving after pressing ctrl+S twice.~~ to Regression: Crash when saving after pressing ctrl+S twice.

2022-03-25 14:10:28 +01:00

Kevin Curry commented

2022-04-04 13:42:11 +02:00

Added subscriber: @kmcurry

Jake was unassigned by Campbell Barton

2022-05-06 14:16:58 +02:00

Julian Eisel was assigned by Campbell Barton

2022-05-06 14:16:58 +02:00

Campbell Barton commented

2022-05-06 14:16:58 +02:00

Added subscriber: @Jake-Faulkner

Julian Eisel commented

2022-05-10 12:24:44 +02:00

Alright so:

D13441: Fix #88570: Crash when saving after pressing ctrl+S twice.: This solves the crash reported here. It tries to do so on the design level by introducing a well defined context that "owns" the file browser and for executing the file operation in. It may unveil some further issues.
D14905: Fix for crash opening the file selector multiple times (by @ideasman42): This is one such issue unveiled by the fix above. It fixes dangling pointers.
D13459: Restrict temp/Maximized/Fullscreen window editing (by @Jake-Faulkner): This prevents more undefined state that causes issues. Editing of temporary/modal screens is supposed to be disabled, see 87aca8bd02, but that commit didn't cover enough cases.

Alright so: - [D13441: Fix #88570: Crash when saving after pressing ctrl+S twice.](https://archive.blender.org/developer/D13441): This solves the crash reported here. It tries to do so on the design level by introducing a well defined context that "owns" the file browser and for executing the file operation in. It may unveil some further issues. - [D14905: Fix for crash opening the file selector multiple times](https://archive.blender.org/developer/D14905) (by @ideasman42): This is one such issue unveiled by the fix above. It fixes dangling pointers. - [D13459: Restrict temp/Maximized/Fullscreen window editing](https://archive.blender.org/developer/D13459) (by @Jake-Faulkner): This prevents more undefined state that causes issues. Editing of temporary/modal screens is supposed to be disabled, see 87aca8bd02, but that commit didn't cover enough cases.

Julian Eisel commented

2022-05-10 12:25:25 +02:00

Added subscriber: @ideasman42