Blender 2.83.15 is also not affected (on Windows)

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

Interesting, in Linux I cannot reproduce it in 2.91.

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

@Dalai Felinto (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: 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.

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 T88570#1168210, @Harley Acheson (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.

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.

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?

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

Caused by rB796412dca0a5: UI: Allow registering File Browser as child of other child windows btw.

@Julian Eisel (Severin):I know you have a fix ready already, mind getting that reviewed/pushed somehow?

Alright so:

• D13441: Fix T88570: 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 @Campbell Barton (campbellbarton)): This is one such issue unveiled by the fix above. It fixes dangling pointers.
• D13459: Restrict temp/Maximized/Fullscreen window editing (by @Jake (Welp)): This prevents more undefined state that causes issues. Editing of temporary/modal screens is supposed to be disabled, see rB87aca8bd02bc, but that commit didn't cover enough cases.