Crash on Back to Previous #64045

New Issue

ChristopherAnderssarian · 2019-05-01T00:44:25+02:00

2019-05-01 00:44:25 +02:00

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

Back to Previous.blend

Exact steps for others to reproduce the error from scratch

(not the same as the attached file)

Open 2.79
{key shift} + {key 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: {#57655}

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...

**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 ](https://developer.blender.org/p/Christopher_Anderssarian/) **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 [Back to Previous.blend](https://archive.blender.org/developer/F6996509/Back_to_Previous.blend) **Exact steps for others to reproduce the error from scratch** (not the same as the attached file) - Open 2.79 - {key shift} + {key 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: {#57655}* 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...

ChristopherAnderssarian commented

2019-05-01 00:44:25 +02:00

Added subscriber: @ChristopherAnderssarian

Stefano Bonicatti commented

2019-05-01 12:48:23 +02:00

Added subscriber: @Smjert

Stefano Bonicatti commented

2019-05-01 12:48:23 +02:00

OS: ArchLinux

I've tested with a Debug build (commit 60e71cba5b) 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

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 ```

Stefano Bonicatti commented

2019-05-01 18:23:15 +02:00

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:

ED_workspace_change() is called. There initially screenOld is = "screenA", screenNew is = "screenB".
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".
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).
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.

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: - `ED_workspace_change()` is called. There initially screenOld is = "screenA", screenNew is = "screenB". - `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". - `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). - `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.

Julian Eisel was assigned by Sebastian Parborg

2019-05-02 12:02:10 +02:00

blender-admin commented

2019-05-04 15:27:31 +02:00

This issue was referenced by 94a064c0e9

This issue was referenced by 94a064c0e95871cd23fd6208f56f4e016a418327

Julian Eisel commented

2019-05-04 15:33:24 +02:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2019-05-04 15:33:24 +02:00

Julian Eisel commented

2019-05-04 15:43:15 +02:00

Two notes:

This bug seems to have been there since 2.5, I think since 6634ed9a87. (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.

Two notes: * This bug seems to have been there since 2.5, I think since 6634ed9a87. (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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash on Back to Previous #64045