godot: Running a scene/game from the editor makes the game crash after one frame

Operating system or device - Godot version: Arch Linux 64 Bit, current master

Issue description (what happened, and what was expected): When trying to run a scene or the whole project from the editor the game crashes after one frame.

_ready() run fine and _process() runs once. After that the window just closes without further information.

Running the project from a terminal works just fine.

Steps to reproduce: Open a project in the editor and try to run it. Try to run a scene from the editor. Try to do the same but from a terminal.

Link to minimal example project (optional but very welcome): test.zip

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 29 (26 by maintainers)

Commits related to this issue

Fix a pesky bug in marshalls.cpp/encode_variant Fixes #7556 running game from editor on LLVM builds. — committed to bojidar-bg/godot by bojidar-bg 7 years ago
Fix a pesky bug in marshalls.cpp/encode_variant Fixes #7556 running game from editor on LLVM builds. — committed to groscalin/godot by bojidar-bg 7 years ago

Most upvoted comments

Reopening as I found a fix and with that the culprit.

I like LLVM. So I always use use_llvm=yes when building Godot. If I compile with clang this bug occurs. If I compile with gcc everything is fine.

The problems has to lie in the profiler/debugger. I once saw the famous shit?: ... error, so there’s something going on with closing connections.

karroffel on Mar 14, 2017

Found the bug. core/io/packet_peer.cpp:91 uses alloca to allocate the memory that holds the package content.

The call to put_packet() causes a segfault, I still don’t know why, but I changed the allocation to use memalloc() and free it with memfree() afterwards.

I suspect alignment to be the problem here, I’m not sure though. I’m looking for a nicer fix, because allocating heap memory so frequently will result in bad performance.

karroffel on Apr 10, 2017

This is my first time using gdb so I could be wrong, but I think I narrowed it down to a segfault in the launched game process.

Thread 2.1 "godot.x11.tools" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7f33380 (LWP 6427)]
0x000000000271f16d in PacketPeer::put_var (this=0x3bd6e30, p_packet=...) at core/io/packet_peer.cpp:96
96		return put_packet(buf, len);

Backtrace:

(gdb) bt
#0  0x000000000271f16d in PacketPeer::put_var (this=0x3bd6e30, p_packet=...) at core/io/packet_peer.cpp:96
#1  0x0000000002609c39 in ScriptDebuggerRemote::idle_poll (this=0x3bd6ad0) at core/script_debugger_remote.cpp:811
#2  0x0000000000d4f967 in Main::iteration () at main/main.cpp:1612
#3  0x0000000000d34e5e in OS_X11::run (this=0x7fffffffdc18) at platform/x11/os_x11.cpp:1917
#4  0x0000000000d2c24a in main (argc=9, argv=0x7fffffffe118) at platform/x11/godot_x11.cpp:49

Frame info:

(gdb) frame
#0  0x000000000271f16d in PacketPeer::put_var (this=0x3bd6e30, p_packet=...) at core/io/packet_peer.cpp:96
96		return put_packet(buf, len);
(gdb) info f
Stack level 0, frame at 0x7fffffffd750:
 rip = 0x271f16d in PacketPeer::put_var (core/io/packet_peer.cpp:96); saved rip = 0x2609c39
 called by frame at 0x7fffffffd9d0
 source language c++.
 Arglist at 0x7fffffffd740, args: this=0x3bd6e30, p_packet=...
 Locals at 0x7fffffffd740, Previous frame's sp is 0x7fffffffd750
 Saved registers:
  rbp at 0x7fffffffd740, rip at 0x7fffffffd748

with the local variables as:

(gdb) info locals
len = 224
err = OK
buf = 0x7fffffffd630 "\025"

opcon on Apr 10, 2017

Can confirm that I also run into this bug if I build the latest master (1c480698ce0e881cbd28f1f0ddba95cee74ca834) with LLVM on Arch Linux, (x64) but not if I build with gcc.

opcon on Apr 10, 2017