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

"Small Deploy with Network Filesystem" crashes Editor when exported end exits #46608

Closed
Firepal opened this issue Mar 2, 2021 · 1 comment · Fixed by #46727
Closed

"Small Deploy with Network Filesystem" crashes Editor when exported end exits #46608

Firepal opened this issue Mar 2, 2021 · 1 comment · Fixed by #46727

Comments

@Firepal
Copy link

Firepal commented Mar 2, 2021

Godot version:

3.2.4.rc (built earlier today)

OS/device including version:

Editor: Windows 10
Target: Oculus Quest 2 (most likely affects any Android device)

Issue description:

Exiting an Android-exported game with "Small Deploy with Network Filesystem" enabled, causes the Editor to crash and print:

WARNING: Thread::~Thread: A Thread object has been destroyed without wait_to_finish() having been called on it. Please do so to ensure correct cleanup of the thread.
     At: core\os\thread.cpp:117
ERROR: EditorFileServer::_subthread_start: Condition "err != OK" is true.
   At: editor\fileserver\editor_file_server.cpp:115

This also breaks using One-Click Deploy more than once, as it intentionally closes the game on the exported end.

Steps to reproduce:

  • With a very recently-built 3.2.x Godot, create a project with an Android export preset
  • Enable "Small Deploy with Network Filesystem"
  • One-Click Deploy twice
@Firepal Firepal changed the title "Small Deploy with Network Filesystem" crashes Editor when remote end exits "Small Deploy with Network Filesystem" crashes Editor when exported end exits Mar 2, 2021
@akien-mga akien-mga added this to the 3.2 milestone Mar 3, 2021
@akien-mga
Copy link
Member

akien-mga commented Mar 5, 2021

Tested with 3.2.4 RC 3 on Linux, exporting to a Xiaomi Pocophone F1, and I can reproduce the issue. It's likely caused by Thread changes in #45618.

I could also reproduce it with a build from latest 3.2 (36bec66):

WARNING: ~Thread: A Thread object has been destroyed without wait_to_finish() having been called on it. Please do so to ensure correct cleanup of the thread.
   At: core/os/thread.cpp:117.
ERROR: _subthread_start: Condition "err != OK" is true.
   At: editor/fileserver/editor_file_server.cpp:115.
[Thread 0x7fff82ffe640 (LWP 450049) exited]
terminate called after throwing an instance of 'std::system_error'
  what():  Invalid argument

Thread 26 "godot-3.2" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff8da8a640 (LWP 449251)]
0x00007ffff7aa04b0 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff7aa04b0 in raise () from /lib64/libc.so.6
#1  0x00007ffff7a8b526 in abort () from /lib64/libc.so.6
#2  0x0000000001702e2b in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00000000046eb316 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#4  0x00000000046eb381 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
#5  0x00000000046eb4d4 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x7fff78000c60, tinfo=tinfo@entry=0x60ca4e8 <typeinfo for std::system_error>, dest=dest@entry=0x47644a0 <std::system_error::~system_error()>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:95
#6  0x0000000001704c2f in std::__throw_system_error (__i=22) at ../../../../../libstdc++-v3/src/c++11/system_error.cc:338
#7  0x000000000476498c in std::thread::join (this=0x7fff78000b98) at ../../../../../libstdc++-v3/src/c++11/thread.cc:113
#8  0x00000000043ca454 in Thread::wait_to_finish (this=0x7fff78000b90) at core/os/thread.cpp:96
#9  0x0000000002d5ffc6 in EditorFileServer::_thread_start (s=0x6ab3180) at editor/fileserver/editor_file_server.cpp:303
#10 0x00000000043ca28a in Thread::callback (p_self=0x6ab32c0, p_settings=..., p_callback=0x2d5fd34 <EditorFileServer::_thread_start(void*)>, p_userdata=0x6ab3180) at core/os/thread.cpp:68
#11 0x00000000043cb00b in std::__invoke_impl<void, void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> (
    __f=@0xa44f388: 0x43ca21e <Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*)>) at /usr/include/c++/10/bits/invoke.h:60
#12 0x00000000043cae8e in std::__invoke<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> (
    __fn=@0xa44f388: 0x43ca21e <Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*)>) at /usr/include/c++/10/bits/invoke.h:95
#13 0x00000000043cad49 in std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::_M_invoke<0ul, 1ul, 2ul, 3ul, 4ul> (this=0xa44f368) at /usr/include/c++/10/thread:264
#14 0x00000000043cacae in std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::operator() (this=0xa44f368)
    at /usr/include/c++/10/thread:271
#15 0x00000000043cac92 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> > >::_M_run (this=0xa44f360) at /usr/include/c++/10/thread:215
#16 0x0000000004764740 in std::execute_native_thread_routine (__p=0xa44f360) at ../../../../../libstdc++-v3/src/c++11/thread.cc:80
#17 0x00007ffff7d6fdea in start_thread () from /lib64/libpthread.so.0
#18 0x00007ffff7b5afff in clone () from /lib64/libc.so.6

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

Successfully merging a pull request may close this issue.

5 participants