Page MenuHome

Crash on Back to Previous
Closed, ResolvedPublic

Description

System Information
Operating system: Microsoft Windows 7
GPU: ASUS Strix Radeon Vega 64
CPU: Intel(R) Core(TM) i7-5960X
RAM: 32.0 GB
Full System Information: Here

Blender Version

Broken: 2.80, blender-2.80.0-git.546e20f5a2c0-windows64
Worked:

Short description of error

Pressing back to previous crashes Blender when saved for a inactive workspace on load.

Steps for others to reproduce the crash

  • Open .blend
  • Switch to Motion Tracking workspace
  • Click and Crash

Exact steps for others to reproduce the error from scratch

(not the same as the attached file)

  • Open 2.79
  • + LMB a window to pop a duplicate out
  • Change editor type to Info
  • Move Info to top and add Info to bottom
  • Maximize the top Info editor
  • Close the popped out window
  • Save the file
  • Open in 2.80
  • Goto 'Default.001'
  • Crash on Back to Previous

Related reading: T57655: Crash after opening a v2.79 file saved with maximized area

Strangely enough:
blender-2.80.0-git.a372e5e426e4-windows64
crashes instantly, where as:
blender-2.80.0-git.a372e5e426e4-windows32
takes half a second to crash...

Event Timeline

OS: ArchLinux

I've tested with a Debug build (commit 60e71cba5b0) and I get a crash/assert as soon as I switch to the Motion Tracking workspace:

#0  0x00007ffff042e82f in raise () from /usr/lib/libc.so.6
#1  0x00007ffff0419672 in abort () from /usr/lib/libc.so.6
#2  0x00005555585f4d69 in ED_workspace_change (workspace_new=0x7fffc14f4a08, C=0x7fffe3e63208, wm=0x7fffc0592c08, win=0x7fffc0fdac88) at /home/smjert/Development/blender-git/blender/source/blender/editors/screen/workspace_edit.c:168
#3  0x0000555557b84805 in WM_window_set_active_workspace (C=0x7fffe3e63208, win=0x7fffc0fdac88, workspace=0x7fffc14f4a08) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_window.c:2331
#4  0x0000555557b4c6d9 in wm_event_do_notifiers (C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_event_system.c:426
#5  0x0000555557b476ca in WM_main (C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm.c:421
#6  0x00005555574aaeb8 in main (argc=1, argv=0x7fffffffe358) at /home/smjert/Development/blender-git/blender/source/creator/creator.c:500

That assert seems to conflict with the comment of the previously called function, screen_change_prepare, which states that the returned screen may not always equal to screen_new.

With a Release build (with debug symbols), this is the stack trace I get if I switch to the Motion Tracking workspace and then click Back to Previous:

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
0x00005555561b93d1 in ctx_data_get (C=C@entry=0x7fffe3e63208, member=member@entry=0x555557e9b155 "scene", result=result@entry=0x7fffffffdfe0) at /home/smjert/Development/blender-git/blender/source/blender/blenkernel/intern/context.c:342
342	      ret = cb(C, member, result);
(gdb) bt
#0  0x00005555561b93d1 in ctx_data_get (C=C@entry=0x7fffe3e63208, member=member@entry=0x555557e9b155 "scene", result=result@entry=0x7fffffffdfe0)
    at /home/smjert/Development/blender-git/blender/source/blender/blenkernel/intern/context.c:342
#1  0x00005555561b96c0 in ctx_data_pointer_verify (C=C@entry=0x7fffe3e63208, member=member@entry=0x555557e9b155 "scene", pointer=pointer@entry=0x7fffffffe030)
    at /home/smjert/Development/blender-git/blender/source/blender/blenkernel/intern/context.c:376
#2  0x00005555561ba03c in ctx_data_pointer_verify (pointer=0x7fffffffe030, member=0x555557e9b155 "scene", C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/blenkernel/intern/context.c:952
#3  CTX_data_scene (C=C@entry=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/blenkernel/intern/context.c:952
#4  0x0000555556a8a3f4 in ED_region_do_draw (C=C@entry=0x7fffe3e63208, ar=ar@entry=0x7fffde47a848) at /home/smjert/Development/blender-git/blender/source/blender/editors/screen/area.c:618
#5  0x00005555565a1da2 in wm_draw_window_offscreen (stereo=false, win=0x7fffc13bd408, C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_draw.c:596
#6  wm_draw_window (win=0x7fffc13bd408, C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_draw.c:732
#7  wm_draw_update (C=C@entry=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm_draw.c:895
#8  0x000055555659f600 in WM_main (C=0x7fffe3e63208) at /home/smjert/Development/blender-git/blender/source/blender/windowmanager/intern/wm.c:424
#9  0x0000555556199803 in main (argc=1, argv=0x7fffffffe388) at /home/smjert/Development/blender-git/blender/source/creator/creator.c:500

I'm unfamiliar with this code, but it seems to me that there are some issues in setting what's the correct screen and keep it in sync with all the place that information is saved (plus there's some weirdness added).

So when opening the file the screen is "screenA", then when switching to the Motion Tracking workspace:

  1. ED_workspace_change() is called. There initially screenOld is = "screenA", screenNew is = "screenB".
  2. screen_change_prepare() (workspace_edit.c:167) is called and since screenNew is a maximized screen, it searches the parent which should be in the normal state; then returns it and sets it to screenNew. screenNew is now = "screenC".
  3. screen_change_update() (workspace_edit.c:187) is called, which in turn calls CTX_wm_window_set() which sets a screen to the context, but that screen is not "screenC", it's "screenB" instead (which supposedly is correct because it's the fullscreen one).
  4. screen_change_update() continue and calls BKE_screen_view3d_scene_sync(), passing a screen, which though is "screenC" this time.

So till here what I see is that the new created layout expects "screenB" (which is the fullscreen one) to be set, which it is in the context, but not through BKE_screen_view3d_scene_sync().

Then I removed the assert that the debug build was hitting, to see if I could understand more.
Doing that, nothing crashes when switching to the Motion Tracking workspace, but when I click Back to previous, another assert is hit.
This time it's in screen_edit.c:1181 in the ED_screen_state_toggle() function.

Here it supposedly have to switch back to normal screen ("screenC"), but when it retrieves the normal screen from the screen area, doing sa->full, that screen is actually "screenB", which is the one in fullscreen.
The current screen, taken with WM_window_get_active_screen() is correctly "screenB".

I also tried to track where the screen area sa was taken from, and I ended up in fullscreen_back_exec(), where it takes a screen from the context; that screen is "screenB".
Then it searches inside the screen areas of the screen and it returns the first one that has sa->full set, which for some reason it's itself.

So I "think" there's a initial mistake with setting the screen through BKE_screen_view3d_scene_sync(), but then when the previous button is clicked the screen area holds "strange" information inside.

Hope this is helpful somehow for a patch, I kind of have finished my time looking into this, and I'm not 100% sure what has to be set where.

Sebastian Parborg (zeddb) triaged this task as Confirmed, High priority.

Two notes:

  • This bug seems to have been there since 2.5, I think since rB6634ed9a872ac. (Testing 2.5 Alpha, the issue is present there.) In 2.8 it was quite difficult to replicate without the given .blend file.
  • There's still an issue remaining for 2.8 here: Before clicking "Back to previous", the fullscreen of the newly activated Motion Tracking workspace is corrupt. Except of the global bars, no redraw happens, all regions are regarded as hidden. Checked a bit but not sure if I'll have enough time to fix this. It seems the fullscreen area vertices aren't scaled correctly, making it too small for any regions.