Crash/program shutdown - draw texture in fullscreen
Open, ConfirmedPublic

Description

System Information
Windows 10
(intel i5 quadcore, 16GB RAM, 4k display)
Nvidia Quadro k2200

Blender Version:
2.79.4 (?official?)
Hash: d2e1a14 (don't distinguish between 1 and l)

Description:
Blender crashes after paint stroke in UV editor when editor window full screen - in Cycles, other unconfirmed.

Lacking knowledge to attach .blend file, reachable at "http://pasteall.org/blend/index.php?id=49313"

File:

Exact steps for others to reproduce the error

Attached file:

  1. exit fullscreen
  2. enter fullscreen
  3. stroke -> crash.

New file:
Engine = CYCLES

  1. Unwrap mesh and assign material (method irrelevant)
  2. separate window:
    1. 3D View
    2. UV editor
    3. Node editor (optional)
  3. set 3D view mode to Rendered or Textured
  4. In UV/IMG Editor make New image (1024px, 32b, black/blank in my case)
  5. Set UVeditor mode to texture paint
  6. In Node Editor make image texture node, select new image and connect to arbitrary output shader
  7. test painting on canvas (all views visible), stroke should work normal
  8. set UV Editor to full screen (ctrl-uparrow in my case)
  9. draw on canvas again, crash or program shutdown occurs.

Details

Type
Bug
Philipp Oeser (lichtwerk) triaged this task as Confirmed priority.Apr 17 2018, 3:47 PM

Can confirm this, this is an issue in undo.
When bmain->is_memfile_undo_written is false (happens when going into fullscreen) then a new "MemFile Internal" UndoStep is pushed to the stack as well as step_init on the stack gets null.
If thats the case -- plus the name thats passed to BKE_undosys_step_push_with_type() is null (which can happen, but thats not always harmful) the crash happens in BLI_strncpy.

Had a quick look and something like

1
2
3diff --git a/source/blender/blenkernel/intern/undo_system.c b/source/blender/blenkernel/intern/undo_system.c
4index 5a0081bff16..ad9ac56620d 100644
5--- a/source/blender/blenkernel/intern/undo_system.c
6+++ b/source/blender/blenkernel/intern/undo_system.c
7@@ -420,7 +420,7 @@ bool BKE_undosys_step_push_with_type(UndoStack *ustack, bContext *C, const char
8​ UndoStep *us = ustack->step_init ? ustack->step_init : MEM_callocN(ut->step_size, __func__);
9​ ustack->step_init = NULL;
10​ if (us->name[0] == '\0') {
11- BLI_strncpy(us->name, name, sizeof(us->name));
12+ BLI_strncpy(us->name, name ? name : ustack->step_active->name, sizeof(us->name));
13​ }
14​ us->type = ut;
15​ /* initialized, not added yet. */
will fix, but I am unsure if this has undesired consequences.

As @Campbell Barton (campbellbarton) was rewriting undo, assigning to him.

I was going over related reports to see whether these can be merged and just for completeness: here is the backtrace

1  BLI_strnlen                     string.c           757  0x2a487e2 
2  BLI_strncpy                     string.c           116  0x2a47512 
3  BKE_undosys_step_push_with_type undo_system.c      423  0x276e204 
4  BKE_undosys_step_push           undo_system.c      448  0x276e343 
5  ED_image_undo_push_end          paint_image_undo.c 358  0x1e02c9e 
6  paint_stroke_done               paint_image.c      576  0x1de542f 
7  stroke_done                     paint_stroke.c     754  0x1e0bc7f 
8  paint_stroke_modal              paint_stroke.c     1176 0x1e0cfa8