GPv3: Crash when undoing conversion from GPv2 #117858

New Issue

Closed

opened 2024-02-05 16:55:54 +01:00 by Lukas Tönne · 12 comments

Lukas Tönne commented

2024-02-05 16:55:54 +01:00

Member

System Information
Operating system: Linux-6.7.2-gentoo-r1-x86_64-AMD_Ryzen_9_7950X_16-Core_Processor-with-glibc2.38 64 Bits, X11 UI
Graphics card: AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 17.0.6, DRM 3.56, 6.7.2-gentoo-r1) AMD 4.6 (Core Profile) Mesa 23.3.4

Blender Version
Broken: version: 4.1.0 Alpha, branch: Unknown, commit date: Unknown Unknown, hash: Unknown
Worked: n/a

Short description of error
Converting a GPv2 object to GPv3 and then undoing crashes Blender.

Exact steps for others to reproduce the error
Get a GPv2 test file (for example here: https://cloud.blender.org/p/gallery/5b642e25bf419c1042056fc6).
Run Object > Convert > Grease Pencil v3 from the menu.
Ctrl+Z to undo, crashes in bounds_min_max_eval

**System Information** Operating system: Linux-6.7.2-gentoo-r1-x86_64-AMD_Ryzen_9_7950X_16-Core_Processor-with-glibc2.38 64 Bits, X11 UI Graphics card: AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 17.0.6, DRM 3.56, 6.7.2-gentoo-r1) AMD 4.6 (Core Profile) Mesa 23.3.4 **Blender Version** Broken: version: 4.1.0 Alpha, branch: Unknown, commit date: Unknown Unknown, hash: `Unknown` Worked: n/a **Short description of error** Converting a GPv2 object to GPv3 and then undoing crashes Blender. **Exact steps for others to reproduce the error** Get a GPv2 test file (for example here: https://cloud.blender.org/p/gallery/5b642e25bf419c1042056fc6). Run _Object > Convert > Grease Pencil v3_ from the menu. Ctrl+Z to undo, crashes in `bounds_min_max_eval`

Lukas Tönne added the

labels 2024-02-05 16:55:54 +01:00

Lukas Tönne added this to the Grease Pencil project 2024-02-05 16:56:00 +01:00

Pratik Borhade commented

2024-02-06 05:08:26 +01:00

Member

Can confirm the crash.

Can confirm the crash.

Pratik Borhade added

and removed

labels 2024-02-06 05:08:36 +01:00

Lukas Tönne changed title from ~~GPv3: Crash when undoing conversion to GPv2~~ to GPv3: Crash when undoing conversion from GPv2

2024-02-06 09:05:28 +01:00

Philipp Oeser added the

label 2024-02-12 14:06:35 +01:00

Philipp Oeser commented

2024-02-12 14:06:54 +01:00

Member

Raising the prio here since it is a crasher (and not an unlikely one to run into)

Raising the prio here since it is a crasher (and not an unlikely one to run into)

Philipp Oeser added

and removed

labels 2024-02-12 14:07:03 +01:00

Philipp Oeser referenced this issue

2024-02-13 13:45:07 +01:00

Blender Crash when undo GP2 to GP3 conversion #113820

Bastien Montagne added

and removed

labels 2024-03-01 14:20:15 +01:00

Bastien Montagne commented

2024-03-01 14:20:50 +01:00

Owner

@lichtwerk GPv3 is still experimental, as such I don't think crashers should get high prio by default ?

@lichtwerk GPv3 is still experimental, as such I don't think crashers should get high prio by default ?

Philipp Oeser commented

2024-03-01 14:29:56 +01:00

Member

@mont29 : this was discussed with @filedescriptor

@mont29 : this was discussed with @filedescriptor

Falk David commented

2024-03-01 14:31:02 +01:00

Member

Looks like a crash that we should be able to fix. Will take a look.

Looks like a crash that we should be able to fix. Will take a look.

Bastien Montagne commented

2024-03-01 14:50:41 +01:00

Owner

The issue is that after undo, the ob->runtime->geometry_set_eval is still containing some Grease Pencil (aka GPv3) data, some how it would look like depsgraph fails at clearing this geometryset data in the evaluated object?

The issue is that after undo, the `ob->runtime->geometry_set_eval` is still containing some Grease Pencil (aka GPv3) data, some how it would look like depsgraph fails at clearing this geometryset data in the evaluated object?

Falk David commented

2024-03-01 15:32:06 +01:00

Member

Hm I'm not sure I understand how the ob->runtime->geometry_set_eval pointer is kept after the memfile was loaded. That seems to me the main issue. Is that some sort of optimization? I suppose that there needs to be something that clears those when the object type changes. In any case, this is outside of my knowledge. @JacquesLucke Could you take a look?

Hm I'm not sure I understand how the `ob->runtime->geometry_set_eval` pointer is kept after the memfile was loaded. That seems to me the main issue. Is that some sort of optimization? I suppose that there needs to be something that clears those when the object type changes. In any case, this is outside of my knowledge. @JacquesLucke Could you take a look?

Bastien Montagne commented

2024-03-01 17:42:28 +01:00

Owner

When undoing, we do not recreate fully the depsgraph anymore, but rather tag (or replay) 'backward' all the ID_RECALC tagging for each ID. So the object here should have the recalc geometry tag (plus the fact that its obdata is now pointing to different ID, some relation rebuild of the depsgraph too). But is suspect the depsgraph (or the code handling the geometry set) does not expect a change in obdata type, which in this case would require getting rid of all geometry set (since legacy GP does not use that system afaik)?

When undoing, we do not recreate fully the depsgraph anymore, but rather tag (or replay) 'backward' all the `ID_RECALC` tagging for each ID. So the object here should have the recalc geometry tag (plus the fact that its obdata is now pointing to different ID, some relation rebuild of the depsgraph too). But is suspect the depsgraph (or the code handling the geometry set) does not expect a change in obdata type, which in this case would require getting rid of all geometry set (since legacy GP does not use that system afaik)?

Falk David commented

2024-03-01 17:51:13 +01:00

Member

which in this case would require getting rid of all geometry set (since legacy GP does not use that system afaik)?

Yes, I believe so. Don't know where that would have to be changed though.

> which in this case would require getting rid of all geometry set (since legacy GP does not use that system afaik)? Yes, I believe so. Don't know where that would have to be changed though.

Jacques Lucke commented

2024-04-10 15:27:12 +02:00

Member

Is this still an issue? I just tested it using this file and it seemed to work fine. If it's still an issue, please provide a specific example file.

Is this still an issue? I just tested it using [this](https://cloud.blender.org/p/gallery/5edd13a01e5ba50266481719) file and it seemed to work fine. If it's still an issue, please provide a specific example file.

Falk David commented

2024-04-10 15:31:20 +02:00

Member

Just tested this again as well, and it seems to work fine for me. I'll let @LukasTonne confirm and (potentially) close the issue :)

Just tested this again as well, and it seems to work fine for me. I'll let @LukasTonne confirm and (potentially) close the issue :)

Lukas Tönne commented

2024-04-10 15:46:58 +02:00

Author

Member

Yes, fixed now.

Yes, fixed now.

Lukas Tönne closed this issue

2024-04-10 15:47:01 +02:00

Blender Bot added

and removed

labels 2024-04-10 15:47:03 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

6 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117858

No description provided.