Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disapperaring nodes after reparenting #27222

Closed
ripperdave opened this issue Mar 19, 2019 · 14 comments · Fixed by #32412
Closed

disapperaring nodes after reparenting #27222

ripperdave opened this issue Mar 19, 2019 · 14 comments · Fixed by #32412

Comments

@ripperdave
Copy link

Godot version:
3.1

OS/device including version:
Windows 7 SP1

Issue description:
Editor issue | Persiting node | Reparenting | saving scene | High impact | reproducable

Child nodes dissapears after reparenting Character scene.
Should not delete nodes after reparenting

Steps to reproduce:
1, Open Main and Character scene.
2, Select Character scene. Add child node Position2d to character.
3, Select Position2d - Make scene root.
4, Save Character scene. - Important step
5, Switch to Main scene and switch back to character.
6, Character scene will be empty. Only Position2d node will be available.

Note: I reparented couple of times and saved the scene. Godot crashed :(
Thank you.

Snow31_disappearingNodes.zip

@follower
Copy link
Contributor

follower commented Mar 24, 2019

IMO this is a serious issue as it leads to data loss.

In addition to the examples in this issue and #27246, the node deletion occurred for me when I changed the type of an "arbitrary" child node (i.e. it wasn't the old or new root node).

Due to the part of the node tree I was looking at, the deletion of the nodes wasn't immediately apparent so it wasn't until some time later that I even noticed that the nodes had been deleted. By which time it wasn't obvious what had caused the issue.

It was only later when I went back to re-create my scene that I noticed that it was the "Change Type" step that triggered the deletion.

In addition when I hovered over the node (maybe the eye?) Godot crashed:

Process:         Godot [...]
Path:            /Users/USER/*/Godot-3.1.app/Contents/MacOS/Godot
Identifier:      org.godotengine.godot
Version:         3.1 (3.1)

[...]

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000030

VM Regions Near 0x30:
--> 
    __TEXT                 00000001080bf000-000000010b5ff000 [ 53.2M] r-x/rwx SM=COW  /Users/USER/*/Godot-3.1.app/Contents/MacOS/Godot

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8d294866 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff83c6735c pthread_kill + 92
2   libsystem_c.dylib             	0x00007fff8508eb26 abort + 125
3   org.godotengine.godot         	0x00000001080c1e02 handle_crash(int) + 2898
4   libsystem_platform.dylib      	0x00007fff89da35aa _sigtramp + 26
5   ???                           	0x00007fdd9a841e80 0 + 140589756849792
6   com.apple.GeForceGLDriver     	0x00001234402b9706 0x123440000000 + 2856710
7   com.apple.GeForceGLDriver     	0x00001234401dd19b 0x123440000000 + 1954203
8   com.apple.GeForceGLDriver     	0x00001234401e2f4a 0x123440000000 + 1978186
9   com.apple.GeForceGLDriver     	0x00001234402e0760 0x123440000000 + 3016544
10  libGPUSupportMercury.dylib    	0x00007fff88b89f8e gldUpdateDrawFramebuffer + 168
11  GLEngine                      	0x00007fff8703c407 gleUpdateDrawFramebufferState + 525
12  GLEngine                      	0x00007fff8703d60c gleDoDrawDispatchCoreGL3 + 104
13  GLEngine                      	0x00007fff86ff1d9a gleDrawArraysOrElements_Entries_Body + 116
14  GLEngine                      	0x00007fff86feb29b glDrawArrays_GL3Exec + 194
15  org.godotengine.godot         	0x00000001088d18c9 RasterizerCanvasGLES3::canvas_render_items(RasterizerCanvas::Item*, int, Color const&, RasterizerCanvas::Light*, Transform2D const&) + 59545
16  org.godotengine.godot         	0x000000010a0f443c VisualServerCanvas::render_canvas(VisualServerCanvas::Canvas*, Transform2D const&, RasterizerCanvas::Light*, RasterizerCanvas::Light*, Rect2 const&) + 1868
17  org.godotengine.godot         	0x000000010a12d5d8 VisualServerViewport::_draw_viewport(VisualServerViewport::Viewport*, ARVRInterface::Eyes) + 2936
18  org.godotengine.godot         	0x000000010a12de7a VisualServerViewport::draw_viewports() + 714
19  org.godotengine.godot         	0x000000010a103623 VisualServerRaster::draw(bool, double) + 323
20  org.godotengine.godot         	0x00000001080f69ff Main::iteration() + 959
21  org.godotengine.godot         	0x00000001080cc407 OS_OSX::run() + 631
22  org.godotengine.godot         	0x00000001080cf13b main + 811
23  libdyld.dylib                 	0x00007fff83c575fd start + 1

This crash occurred again when I re-opened the project and hovered the mouse pointer over the node:

Process:         Godot [...]
Path:            /Users/USER/*/Godot-3.1.app/Contents/MacOS/Godot
Identifier:      org.godotengine.godot
Version:         3.1 (3.1)

[...]

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000030

VM Regions Near 0x30:
--> 
    __TEXT                 0000000100030000-0000000103570000 [ 53.2M] r-x/rwx SM=COW  /Users/USER/*/Godot-3.1.app/Contents/MacOS/Godot

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8d294866 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff83c6735c pthread_kill + 92
2   libsystem_c.dylib             	0x00007fff8508eb26 abort + 125
3   org.godotengine.godot         	0x0000000100032e02 handle_crash(int) + 2898
4   libsystem_platform.dylib      	0x00007fff89da35aa _sigtramp + 26
5   ???                           	0x00007fe2d3484d50 0 + 140612184067408
6   com.apple.GeForceGLDriver     	0x00001234402b9706 0x123440000000 + 2856710
7   com.apple.GeForceGLDriver     	0x00001234401dd19b 0x123440000000 + 1954203
8   com.apple.GeForceGLDriver     	0x00001234401e2f4a 0x123440000000 + 1978186
9   com.apple.GeForceGLDriver     	0x00001234402e0760 0x123440000000 + 3016544
10  libGPUSupportMercury.dylib    	0x00007fff88b89f8e gldUpdateDrawFramebuffer + 168
11  GLEngine                      	0x00007fff8703c407 gleUpdateDrawFramebufferState + 525
12  GLEngine                      	0x00007fff8703d60c gleDoDrawDispatchCoreGL3 + 104
13  GLEngine                      	0x00007fff86ff1d9a gleDrawArraysOrElements_Entries_Body + 116
14  GLEngine                      	0x00007fff86feb29b glDrawArrays_GL3Exec + 194
15  org.godotengine.godot         	0x00000001008428c9 RasterizerCanvasGLES3::canvas_render_items(RasterizerCanvas::Item*, int, Color const&, RasterizerCanvas::Light*, Transform2D const&) + 59545
16  org.godotengine.godot         	0x000000010206543c VisualServerCanvas::render_canvas(VisualServerCanvas::Canvas*, Transform2D const&, RasterizerCanvas::Light*, RasterizerCanvas::Light*, Rect2 const&) + 1868
17  org.godotengine.godot         	0x000000010209e5d8 VisualServerViewport::_draw_viewport(VisualServerViewport::Viewport*, ARVRInterface::Eyes) + 2936
18  org.godotengine.godot         	0x000000010209ee7a VisualServerViewport::draw_viewports() + 714
19  org.godotengine.godot         	0x0000000102074623 VisualServerRaster::draw(bool, double) + 323
20  org.godotengine.godot         	0x00000001000679ff Main::iteration() + 959
21  org.godotengine.godot         	0x000000010003d407 OS_OSX::run() + 631
22  org.godotengine.godot         	0x000000010004013b main + 811
23  libdyld.dylib                 	0x00007fff83c575fd start + 1

(1) Edited to add crash logs

(2) Edited to add: Just discovered that if I close & reopen the editor/project before changing the node type the deletion & crash doesn't occur. To me that suggests the underlying issue is related to bad state occurring from the root change.

@follower
Copy link
Contributor

follower commented Mar 24, 2019

The code in question seems to be located here:

case TOOL_MAKE_ROOT: {
List<Node *> nodes = editor_selection->get_selected_node_list();
ERR_FAIL_COND(nodes.size() != 1);
Node *node = nodes.front()->get();
Node *root = get_tree()->get_edited_scene_root();
if (node == root)
return;
//check that from node to root, all owners are right
if (root->get_scene_inherited_state().is_valid()) {
accept->set_text(TTR("Can't reparent nodes in inherited scenes, order of nodes can't change."));
accept->popup_centered_minsize();
return;
}
if (node->get_owner() != root) {
accept->set_text(TTR("Node must belong to the edited scene to become root."));
accept->popup_centered_minsize();
return;
}
if (node->get_filename() != String()) {
accept->set_text(TTR("Instantiated scenes can't become root"));
accept->popup_centered_minsize();
return;
}
editor_data->get_undo_redo().create_action(TTR("Make node as Root"));
editor_data->get_undo_redo().add_do_method(node->get_parent(), "remove_child", node);
editor_data->get_undo_redo().add_do_method(root->get_parent(), "remove_child", root);
editor_data->get_undo_redo().add_do_method(node, "add_child", root);
editor_data->get_undo_redo().add_do_method(editor, "set_edited_scene", node);
editor_data->get_undo_redo().add_do_method(node, "set_filename", root->get_filename());
editor_data->get_undo_redo().add_do_method(root, "set_filename", String());
editor_data->get_undo_redo().add_do_method(node, "set_owner", (Object *)NULL);
editor_data->get_undo_redo().add_do_method(root, "set_owner", node);
_node_replace_owner(root, root, node, MODE_DO);
editor_data->get_undo_redo().add_undo_method(root, "set_filename", root->get_filename());
editor_data->get_undo_redo().add_undo_method(node, "set_filename", String());
editor_data->get_undo_redo().add_undo_method(node, "remove_child", root);
editor_data->get_undo_redo().add_undo_method(editor, "set_edited_scene", root);
editor_data->get_undo_redo().add_undo_method(node->get_parent(), "add_child", node);
editor_data->get_undo_redo().add_undo_method(root, "set_owner", (Object *)NULL);
editor_data->get_undo_redo().add_undo_method(node, "set_owner", root);
_node_replace_owner(root, root, root, MODE_UNDO);
editor_data->get_undo_redo().add_do_method(scene_tree, "update_tree");
editor_data->get_undo_redo().add_undo_method(scene_tree, "update_tree");
editor_data->get_undo_redo().add_undo_reference(root);
editor_data->get_undo_redo().commit_action();
} break;

The "blame" history suggests a number of "recent" changes have occurred in this piece of code, including some dealing with similar issues:

(1) Edited to add: Including one commit entitled "Fixed setting node as root deleting all non-children of that node." here: 6f96db4

(2) Edited to add: Related: #22921?

@akien-mga akien-mga added this to the 3.2 milestone Apr 8, 2019
@follower
Copy link
Contributor

Additional context: I've since experienced the gldUpdateDrawFramebuffer()-related crash outside of the original disappearing nodes issue--so I think the crash is not related to the disappearing nodes but rather an issue with GLES3 (where the crash occurs) vs GLES2 (where the crash doesn't occur).

@v-i-m
Copy link

v-i-m commented Jun 26, 2019

Similar problem here. I rerooted a simple Node2D with not much in it, just a Sprite, instantiated it, renamed it... and then the instance got nuked, its interior got replaced by empty Node2Ds, and now the project was erroring, and I was unable to save.

This, for anyone who doesn't know that they shouldn't REROOT + RENAME, or whatever other bug is related to rerooting, is a catastrophic Godot bug. It can destroy complex hierarchies of nodes, which in turn can probably wreck an entire project. Pls up the priority as much as possible, and fix this asap.

@Zireael07
Copy link
Contributor

#29865 is likely yet another report of the same problem.

@regakakobigman
Copy link

regakakobigman commented Jun 26, 2019

There have been a few unofficial reports in the Godot discord that I think are worth mentioning, too.

1 (link)

[10:14 PM] menip: Anyone experience random parts of scene being deleted? Seems I added nodes/renamed others in scene. Without saving, I then renamed some scripts that were attached to said scene. Upon rename seemed all changes got reverted, but scripts were renamed
[10:16 PM] aux4: @menip as in in the editor? i have
[10:16 PM] aux4: i haven't nailed down exactly what has been causing it yet but i think it has something to do with having two scenes open, one with an instance of the other, and then changing the root node of the instanced scene, along with some other magic
[10:16 PM] aux4: and then poof child nodes are gone
[10:17 PM] aux4: planning on filing a bug once i figure out how to repro reliably...

2 (link)

[8:34 PM] Evan: ahhh
[8:34 PM] Evan: so
[8:34 PM] Evan: just made a  node a root of my scene
[8:34 PM] Evan: and it deleted the entire scene i had been working on

@joebentley
Copy link

joebentley commented Jul 17, 2019

I'd like to note that I have the same issue. I'm not sure what's causing it but sometimes I'll look and suddenly one of my nodes will be missing. I'm using macOS, Godot v3.1.1

@programaths
Copy link

Yep, I lost a whole scene too and another guy did report so in Q&A: https://godotengine.org/qa/47401/godot-randomly-deleting-nodes

It also happens "randomly", so it's a show stopper bug!

@KoBeWi
Copy link
Member

KoBeWi commented Aug 27, 2019

Ok, so the reproduction steps in the OP work 100% of the time, always. I used this fact trying to pinpoint the issue. I've been printing children count everywhere, trying to find where the data loss happens.

Ultimately, the issue comes to these steps:

  1. Change root node
  2. Save scene
  3. Change scene tab and back

What happens here:

  1. You change the root
  2. The scene is saved correctly, meaning everything is in place in the .tscn file
  3. When you change tab, all nodes disappear. Everything is fine until you save the scene again, which will remove all nodes from .tscn file.

So the issue is triggered by save and scene tab change. If you save and then reload scene, everything will work correctly.

Now, as for the cause... I have no idea what it is XD I only discovered that commenting out this line:

err = ResourceSaver::save(p_file, sdata, flg);

will prevent nodes from disappearing when switching tabs. This is the line that saves the scene resource to the file. Looks like it might modify the node in some way that breaks the scene tree, but this only happens when you switch tab.

And just now I discovered that you can do above-mentioned steps in 2->1->3 order and it will break too .-.

@follower
Copy link
Contributor

follower commented Aug 28, 2019

Could one or more people please try to reproduce this with a build of the current master or a nightly build from here: https://hugo.pro/projects/godot-builds/?

I briefly/roughly tried to reproduce this issue with a nightly build (Godot Engine v3.2.dev.calinou.de4aabe89) and the issue appeared not to occur.

My guess was that it may have been fixed by #31237 but I'm slightly confused because that PR was by @KoBeWi who mentioned being able to reproduce the issue in #27222 (comment).

Update: It seems the Mac nightly build I was using hadn't been updated for a while so YMMV.

@KoBeWi
Copy link
Member

KoBeWi commented Aug 28, 2019

No, the issue isn't fixed in the latest master branch. I did my tests there. If it works for you in a nightly build, you probably did reproduction steps incorrectly.

@follower
Copy link
Contributor

Thanks for confirming that @KoBeWi.

It seems that #27246 was mis-categorised as duplicate of this issue because that "Make Scene Root" + "Change Type" issue seems to now have been fixed (and was what I was reproducing).

However, when I used the Snow31_disappearingNodes.zip project from the OP in this issue I was able to reproduce the disappearing nodes still with the ~11 day old build I (discovered) I was testing with.

@follower
Copy link
Contributor

FYI: It seems if one notices the nodes have disappeared it's possible to choose "Revert Scene" and they will be recovered--even though the scene tab doesn't have a "(*)" "changed"/"dirty" marker in the name.

@follower
Copy link
Contributor

follower commented Aug 28, 2019

Causing a crash during scene update

Okay, so, the discovery of the "Revert Scene" possibility enabled me to cause a crash that looks like (when I changed to use GLES2 rather than GLES3):

handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00007fff8b26d5aa _sigtramp + 26
[2] 2   libobjc.A.dylib                     0x00007fff8ec9f080 objc_msgSend + 0
[3] EditorNode::_update_scene_tabs() (in Godot) + 319
[4] EditorNode::_notification(int) (in Godot) + 3929
[5] EditorNode::_notificationv(int, bool) (in Godot) + 76
[6] Object::notification(int, bool) (in Godot) + 19
[7] SceneTree::_notify_group_pause(StringName const&, int) (in Godot) + 2470
[8] SceneTree::idle(float) (in Godot) + 600
[9] Main::iteration() (in Godot) + 815
[10] OS_OSX::run() (in Godot) + 410
[11] main (in Godot) + 816
[12] 12  libdyld.dylib                       0x00007fff851215fd start + 1
-- END OF BACKTRACE --

I caused this by loading the project with the Position2D already added to it (as the last item in the tree) and then:

  1. "Make Scene Root" on Position2D.
  2. Save.
  3. Switch to "Main". (Observe "Update Scene" progress dialog briefly appears--and scene appears mis-drawn.)
  4. Switch to "Character".
  5. Observe only the Position2D node is in the tree.
  6. "Revert Scene".
  7. Observe Position2D node now has Character node & its children again.
  8. "Make Scene Root" on Character node.
  9. Save.
  10. Switch to "Main".
  11. Switch to "Character".
  12. Observe Character node has its children except for Position2D.
  13. "Revert Scene".
  14. Observe Character node has its children including Position2D node.
  15. "Make Scene Root" on Position2D.
  16. Don't Save.
  17. "Make Scene Root" on Character node.
  18. Save.
  19. Switch to "Main".
  20. Observe crash.

(For a quicker crash just do steps 15-20.)

More detail via lldb

With lldb I can get more detail:

Process 85702 stopped
* thread #1: tid = 0x65d2df, 0x000000010a3d1a94 Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010a3d1a94 Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164
Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164:
-> 0x10a3d1a94:  callq  *%rbx
   0x10a3d1a96:  movl   %eax, %ebx
   0x10a3d1a98:  movq   -0x48(%rbp), %rdi
   0x10a3d1a9c:  testq  %rdi, %rdi
(lldb) bt
* thread #1: tid = 0x65d2df, 0x000000010a3d1a94 Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010a3d1a94 Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164
    frame #1: 0x000000010a3d13bf Godot`EditorNode::_update_scene_tabs() + 319
    frame #2: 0x000000010a3d5809 Godot`EditorNode::_notification(int) + 3929
    frame #3: 0x000000010a439a4c Godot`EditorNode::_notificationv(int, bool) + 76
    frame #4: 0x000000010bc572f3 Godot`Object::notification(int, bool) + 19
    frame #5: 0x000000010ac87036 Godot`SceneTree::_notify_group_pause(StringName const&, int) + 2470
    frame #6: 0x000000010ac87648 Godot`SceneTree::idle(float) + 600
    frame #7: 0x000000010971102f Godot`Main::iteration() + 815
    frame #8: 0x00000001096de96a Godot`OS_OSX::run() + 410
    frame #9: 0x00000001096e2e00 Godot`main + 816
    frame #10: 0x00007fff851215fd libdyld.dylib`start + 1
(lldb) thread info
thread #1: tid = 0x65d2df, 0x000000010a3d1a94 Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

(lldb) register read
General Purpose Registers:
       rax = 0x000000010ca5606b  ""
       rbx = 0x0ba9bb4000000001
       rcx = 0x00007fa0c49cc3d8
       rdx = 0x0000000000000004
       rdi = 0x00007fa0bd2d5420
       rsi = 0x00007fff5652e138
       rbp = 0x00007fff5652e180
       rsp = 0x00007fff5652e0e0
        r8 = 0x0000000000000002
        r9 = 0x00007fa0c4900000
       r10 = 0x00007fff5652dfd8
       r11 = 0x00007fff5652dff0
       r12 = 0x00007fa0bd2d5420
       r13 = 0x0000000000000001
       r14 = 0x0000000000000000
       r15 = 0x00007fff5652e1c0
       rip = 0x000000010a3d1a94  Godot`EditorNode::get_object_icon(Object const*, String const&) const + 164
    rflags = 0x0000000000010206
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x000000000d680000

Different crashes with GLES3

Once when I was using GLES3 rather than GLES2 I got:

handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00007fff8b26d5aa _sigtramp + 26
[2] 2   ???                                 0x00007fff505fedf0 0x0 + 140734541852144
[3] RefPtr::RefPtr(RefPtr const&) (in Godot) + 43
[4] Object::get_script() const (in Godot) + 18
[5] EditorNode::get_object_icon(Object const*, String const&) const (in Godot) + 103
[6] EditorNode::_update_scene_tabs() (in Godot) + 319
[7] EditorNode::_notification(int) (in Godot) + 3929
[8] EditorNode::_notificationv(int, bool) (in Godot) + 76
[9] Object::notification(int, bool) (in Godot) + 19
[10] SceneTree::_notify_group_pause(StringName const&, int) (in Godot) + 2470
[11] SceneTree::idle(float) (in Godot) + 600
[12] Main::iteration() (in Godot) + 815
[13] OS_OSX::run() (in Godot) + 410
[14] main (in Godot) + 816
[15] 15  libdyld.dylib                       0x00007fff851215fd start + 1
[16] 16  ???                                 0x0000000000000002 0x0 + 2
-- END OF BACKTRACE --
Abort trap: 6

And multiple times got:

handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00007fff8b26d5aa _sigtramp + 26
[2] 2   ???                                 0x00007fa80e2bd080 0x0 + 140359768985728
[3] 3   GeForceGLDriver                     0x00001234402b9706 gldReadTextureData + 688435
[4] 4   GeForceGLDriver                     0x00001234401dd19b GeForceGLDriver + 1954203
[5] 5   GeForceGLDriver                     0x00001234401e2f4a GeForceGLDriver + 1978186
[6] 6   GeForceGLDriver                     0x00001234402e0760 gldReadTextureData + 848269
[7] 7   libGPUSupportMercury.dylib          0x00007fff8a053f8e gldUpdateDrawFramebuffer + 168
[8] 8   GLEngine                            0x00007fff88506407 gleUpdateDrawFramebufferState + 525
[9] 9   GLEngine                            0x00007fff8850760c gleDoDrawDispatchCoreGL3 + 104
[10] 10  GLEngine                            0x00007fff884bbd9a gleDrawArraysOrElements_Entries_Body + 116
[11] 11  GLEngine                            0x00007fff884b529b glDrawArrays_GL3Exec + 194
[12] RasterizerCanvasGLES3::canvas_render_items(RasterizerCanvas::Item*, int, Color const&, RasterizerCanvas::Light*, Transform2D const&) (in Godot) + 59031
[13] VisualServerCanvas::render_canvas(VisualServerCanvas::Canvas*, Transform2D const&, RasterizerCanvas::Light*, RasterizerCanvas::Light*, Rect2 const&) (in Godot) + 504
[14] VisualServerViewport::_draw_viewport(VisualServerViewport::Viewport*, ARVRInterface::Eyes) (in Godot) + 2587
[15] VisualServerViewport::draw_viewports() (in Godot) + 1202
[16] VisualServerRaster::draw(bool, double) (in Godot) + 324
[17] Main::iteration() (in Godot) + 990
[18] OS_OSX::run() (in Godot) + 410
[19] main (in Godot) + 816
[20] 20  libdyld.dylib                       0x00007fff851215fd start + 1
[21] 21  ???                                 0x0000000000000002 0x0 + 2
-- END OF BACKTRACE --
Abort trap: 6

Sometimes it was when swapping tabs, other times when rendering tab previews--I think it probably just implies that the GLES3 is more fussy than GLES2 when it encounters bad data.

Next steps

I suspect further debugging would probably be best with doing my own build but I'm already multiple yaks deep on that front but hopefully these notes are helpful for further investigation.

Also, I wondered if this might be related: #31736

Edit #1: I suspect running with Valgrind might be helpful.

Edit #2: I also suspect revisiting 6f96db4 might be helpful--particularly by someone who understands the undo/redo & parenting system better than I. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants