Page MenuHome

Crash when switching render slots while render is in progress
Closed, ResolvedPublic

Description

System Information
Operating system: macOS-11.3-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.4.17

Blender Version
Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-01 15:22, hash: rB7c5e00965533
Worked: 2.91.2

Short description of error
When a render is in progress, if I press J a few times to cycle between render slots, Blender wil crash.

Exact steps for others to reproduce the error
Default scene
Switch from Eevee to Cycles
Press F12 to render
In the render view, press J to switch render slots a few times while the render is in progress; Blender will invariably crash after doing this a few times (sometimes up to 10-20 times, sometimes faster).

Crash log:

Event Timeline

I just want to say that I can reproduce this issue on Linux with a Nvidia GPU in 2.92, 2.93 and 3.0. But I'll leave the triaging of this report to others.

backtrace
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(BLI_system_backtrace+0x20) [0xa50dc20]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0xf49fea]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bd60) [0x7fa0fd53fd60]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(GPU_texture_update_sub+0x42) [0x853fac2]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0xf892b4]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0xf8959c]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0xf89904]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0xf89a98]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0x143ca63]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0x143ce46]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0x142da36]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(DRW_draw_render_loop_2d_ex+0x474) [0x142fc04]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender() [0x1cacee2]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(ED_region_do_draw+0x861) [0x188bd21]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(wm_draw_update+0x51e) [0x12dee2e]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(WM_main+0x30) [0x12dcc40]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(main+0x31d) [0xe7786d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fa0fd52ad0a]
/mnt/HDD/Home/Alaska/Documents/blender-git/build_linux/bin/blender(_start+0x2a) [0xf4699a]

Python backtrace

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Mon, May 3, 3:42 PM
Philipp Oeser (lichtwerk) claimed this task.

Can confirm, will check.

Philipp Oeser (lichtwerk) triaged this task as High priority.

Apparently rBb4f0d5247338 is not safe all the way, I am entering GPU_texture_mipmap_mode with a NULL tex

Will step down though, @Brecht Van Lommel (brecht) or @Jeroen Bakker (jbakker) are probably faster fixing this.

Will dare setting this to High prio, it has been around since 2.92, but it is a regression and an operation that is done pretty often I think.

1  blender::gpu::Texture::format_flag_get gpu_texture_private.hh 227  0xddd0c9c 
2  GPU_texture_mipmap_mode                gpu_texture.cc         487  0xddd04e0 
3  image_get_gpu_texture                  image_gpu.c            419  0x35fbe8e 
4  BKE_image_get_gpu_texture              image_gpu.c            441  0x35fbf29 
5  space_image_gpu_texture_get            image_engine.c         138  0x3e7ed2a 
6  image_gpu_texture_get                  image_engine.c         171  0x3e7ee00 
7  image_cache_image                      image_engine.c         190  0x3e7eee4 
8  IMAGE_cache_init                       image_engine.c         327  0x3e7f4e5 
9  drw_engines_cache_init                 draw_manager.c         1052 0x3e65b7d 
10 DRW_draw_render_loop_2d_ex             draw_manager.c         2110 0x3e684d5 
11 DRW_draw_view                          draw_manager.c         1520 0x3e66df7 
12 image_main_region_draw                 space_image.c          653  0x4c055c7 
13 ED_region_do_draw                      area.c                 558  0x45a9235 
14 wm_draw_window_offscreen               wm_draw.c              724  0x3b8b194 
15 wm_draw_window                         wm_draw.c              864  0x3b8b741 
16 wm_draw_update                         wm_draw.c              1065 0x3b8bd79 
17 WM_main                                wm.c                   653  0x3b884a3 
18 main                                   creator.c              520  0x35983f2

@Philipp Oeser (lichtwerk), I can't reproduce the crash in latest master (rB9f1e20e7).

From the code, it's not clear to me how tex can become NULL in GPU_texture_mipmap_mode?

if (*tex) {
  GPU_texture_wrap_mode(*tex, true, false);

  if (GPU_mipmap_enabled()) {
    GPU_texture_generate_mipmap(*tex);
    if (ima) {
      ima->gpuflag |= IMA_GPU_MIPMAP_COMPLETE;
    }
    GPU_texture_mipmap_mode(*tex, true, true);
  }
  else {
    GPU_texture_mipmap_mode(*tex, false, true);
  }
}

This is what happens here (this time I had to hammer J quite often, but it can happen with less presses, too):

could this be freed from another thread or so?

I could reproduce now, you're right about the threads.