Page MenuHome

GPencil: Crash when opening a file that has a gpencil data block with layer transforms
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-5.15.23-76051523-generic-x86_64-with-glibc2.34 64 Bits
Graphics card: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 510.54

Blender Version
Broken: version: 3.2.0 Alpha, branch: master
Worked: 3.1

Caused by rB7ca13eef7c33: Improve multi-user gpencil data performance with modifiers

Short description of error
Blender crashes on opening a file that was saved with layer transforms.

Exact steps for others to reproduce the error

  1. Open Blender with the 2D Animation template.
  2. Change the layer transform in the object data properties panel under "Transform".
  3. Save the file and reopen it -> Blender crashes.

or

  1. Open test file -> Blender crashes.

Investigation

The crash occurs when a grease pencil data-block is expanded for the first time and then tries to access the gpf->runtime.gpf_orig pointer in copy_frame_to_eval_cb from BKE_gpencil_prepare_eval_data. That pointer is NULL.

This is because in deg_update_copy_on_write_datablock when we do a copy on write, we only call BKE_gpencil_data_update_orig_pointers in GPencilBackup::restore_to_gpencil if a backup has been created. But RuntimeBackup::init_from_id returns early if deg_copy_on_write_is_expanded is false.

Maybe the solution is to add some logic to update_id_after_copy to make sure the runtime orig pointers are updated.

Event Timeline

Cannot repro here.

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44
version: 3.2.0 Alpha, branch: master, commit date: 2022-03-07 06:49, hash: `rBad2948face07`
Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Mar 7 2022, 3:02 PM

Can confirm now, will bisect

Quick fix hack:

diff --git a/source/blender/depsgraph/intern/eval/deg_eval_copy_on_write.cc b/source/blender/depsgraph/intern/eval/deg_eval_copy_on_write.cc
index 6346bab1fe8..414f031ece4 100644
--- a/source/blender/depsgraph/intern/eval/deg_eval_copy_on_write.cc
+++ b/source/blender/depsgraph/intern/eval/deg_eval_copy_on_write.cc
@@ -41,6 +41,7 @@
 #include "DNA_ID.h"
 #include "DNA_anim_types.h"
 #include "DNA_armature_types.h"
+#include "DNA_gpencil_types.h"
 #include "DNA_mesh_types.h"
 #include "DNA_modifier_types.h"
 #include "DNA_object_types.h"
@@ -733,6 +734,14 @@ void update_id_after_copy(const Depsgraph *depsgraph,
       scene_setup_view_layers_after_remap(depsgraph, id_node, reinterpret_cast<Scene *>(id_cow));
       break;
     }
+    case ID_GD: {
+      bGPdata *gpd_cow = (bGPdata *)id_cow;
+      bGPDlayer *gpl = (bGPDlayer *)(gpd_cow->layers.first);
+      if (gpl != NULL && gpl->runtime.gpl_orig == NULL) {
+        BKE_gpencil_data_update_orig_pointers((bGPdata *)id_orig, gpd_cow);
+      }
+      break;
+    }
     default:
       break;
   }

If the datablock was not copied yet, there is nothing to be backed up from it. So this part of the logic seems to be working as intended.

@Falk David (filedescriptor), your proposed patch looks good and safe.

Fixed by rB21d633f83b3ab09342ad32c4c3d896d3a8308404 but we might want to look into a cleaner solution.

Philipp Oeser (lichtwerk) closed this task as Resolved.Mar 8 2022, 11:19 AM
Philipp Oeser (lichtwerk) claimed this task.

OK, will close then.