Page MenuHome

Crash on saving or opening files with the Full Screen file browser window preference
Closed, ResolvedPublicBUG


System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87

Blender Version
Broken: version: 2.90 (sub 2), branch: master, commit date: 2020-05-19 22:32, hash: rB4f622c9a080b

Short description of error
The file browser crashes when the Full Screen

Exact steps for others to reproduce the error

  • Fresh factory settings
  • Go to preferences/Interface/Editors/Temporary Windows
  • Set the File Browser to Full Screen
  • Now save the blend file

Event Timeline

I can't reproduce the crash.
Can you run blender_debug-gpu.cmd that is included in the download.
After Blender closes, the logs will be in a text file which can be attached here.

Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 26.20.15001.5006

Here they are

I have the same issue. Saving the default cube crashes when file browser set to full screen.
What I find bizarre is that if I start blender with "./blender --debug-all" it doesn't crash.

System Information
Operating system: Linux-5.6.10-custom-x86_64-AMD_A8-5600K_APU_with_Radeon-tm-_HD_Graphics-with-slackware-14.2 64 Bits
Graphics card: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.36.0, 5.6.10-custom, LLVM 10.0.0) X.Org 4.6 (Core Profile) Mesa 20.0.2

Blender Version
Broken: version: 2.83 (sub 17), branch: master, commit date: 2020-05-21 08:18, hash: rBd15efbdc56a3
Worked: blender-2.83-008e96494008-linux64

Julian Eisel (Severin) changed the subtype of this task from "Report" to "Bug".

Probably caused by rB796412dca0a5 (not a 2.83 bug then). Investigating.

No, this is actually caused by rBb75ce05c3b0f, so it is a 2.83 regression.

The crash happens because the cancelling of the file browser removes its screen (as in bScreen). Before rBb75ce05c3b0f, the file browser event wouldn't be handled any further then. After it, it would still be passed to other areas, while the screen pointer was dangling.
All this is very fragile code that has caused many bugs already. It's another example where we would need some kind of "sandboxed" execution for destructive handlers. See D7795.

@Jacques Lucke (JacquesLucke) I think going back to your earlier approach in D7720 is the best solution. It fixes this crash, and also still fixes T75292 & T73579. Would've prefered the more general solution, but the one specific to UI-handlers is still totally acceptable.