Editor crashes when stopping a running scene on Linux

When I run any of the example scenes - the Playground main scene or any of the sub-scenes in …, the Editor dies after I click the play button the second time to stop the scene.

Device: OAK-D-Lite Unity: 2021.2.7f1

OS: Ubuntu 21.10 x86_64 Kernel: 5.13.0-27-lowlatency CPU: Intel i7-7820X @3.60 GHz, 8 physical cores GPU: NVIDIA TITAN RTX, driver version 470.86 Memory: 64 GB

The setup is the same as described in issue #8, only now what I do is:

• open a scene in editor
• push the play button to start preview run
• push the play button to stop preview run
• the editor crashes

I tried to run in gdb again

gdb /opt/unity/2021.2.7f1/Editor/Unity

Only this time there were more bogus signals trapped when I didn’t want to, so to set up gdb:

set mi-async 1
set pagination off
set non-stop on
handle SIGXCPU SIGPWR SIG36 SIG37 nostop noprint
run -projectPath ~/hax/depthai-unity/OAKForUnity/URP/

Now I open the scene in the editor, push the play button, wait for the scene to fully load, go to gdb again and hit Ctrl+C

handle SIGXCPU stop print
continue

Now I hit the play button again to stop the running scene. The Editor dies, and I get a stack trace (actually about 30 killed threads, only number 1 seems to be relevant):

Thread 1 "Unity" received signal SIGXCPU, CPU time limit exceeded.
backward::SignalHandling::sig_handler (signo=0, info=0x3db61d19, _ctx=0xbf7efc623c114bb3) at /home/strazce/.hunter/_Base/062a19a/e4f2f5b/72dac15/Install/include/backward.hpp:4263
4263	  sig_handler(int signo, siginfo_t *info, void *_ctx) {
(gdb) thread 1
[Switching to thread 1 (Thread 0x7fffed3ad340 (LWP 167877))]
#0  backward::SignalHandling::sig_handler (signo=0, info=0x3db61d19, _ctx=0xbf7efc623c114bb3) at /home/strazce/.hunter/_Base/062a19a/e4f2f5b/72dac15/Install/include/backward.hpp:4263
4263	  sig_handler(int signo, siginfo_t *info, void *_ctx) {
(gdb) bt
#0  backward::SignalHandling::sig_handler(int, siginfo_t*, void*) (signo=0, info=0x3db61d19, _ctx=0xbf7efc623c114bb3) at /home/strazce/.hunter/_Base/062a19a/e4f2f5b/72dac15/Install/include/backward.hpp:4263
#1  0x00007ffff0207520 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff020780a in __GI___sigsuspend (set=0x7ffedc5e11a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
#3  0x00007ffedc2a47ac in GC_suspend_handler_inner () at /opt/unity/2021.2.7f1/Editor/Data/MonoBleedingEdge/MonoEmbedRuntime/libmonobdwgc-2.0.so
#4  0x00007ffedc2a4665 in GC_suspend_handler () at /opt/unity/2021.2.7f1/Editor/Data/MonoBleedingEdge/MonoEmbedRuntime/libmonobdwgc-2.0.so
#5  0x00007ffff0207520 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#6  __futex_abstimed_wait_common64 (private=<optimized out>, cancel=true, abstime=0x7fffffffc0f0, op=393, expected=0, futex_word=0x7ffceff36940 <schedulerState+24832>) at futex-internal.c:57
#7  __futex_abstimed_wait_common (cancel=true, private=<optimized out>, abstime=0x7fffffffc0f0, clockid=0, expected=0, futex_word=0x7ffceff36940 <schedulerState+24832>) at futex-internal.c:87
#8  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7ffceff36940 <schedulerState+24832>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x7fffffffc0f0, private=<optimized out>) at futex-internal.c:139
#9  0x00007ffff02617f0 in do_futex_wait (sem=sem@entry=0x7ffceff36940 <schedulerState+24832>, abstime=abstime@entry=0x7fffffffc0f0, clockid=0) at sem_waitcommon.c:112
#10 0x00007ffff0261893 in __new_sem_wait_slow64 (sem=0x7ffceff36940 <schedulerState+24832>, abstime=0x7fffffffc0f0, clockid=0) at sem_waitcommon.c:184
#11 0x00007ffcef4be377 in XLink_sem_timedwait () at /home/strazce/hax/depthai-unity/build/depthai-core/libdepthai-core.so
#12 0x00007ffcef4bb203 in DispatcherWaitEventCompleteTimeout () at /home/strazce/hax/depthai-unity/build/depthai-core/libdepthai-core.so
#13 0x00007ffcef4b8dff in XLinkResetRemoteTimeout () at /home/strazce/hax/depthai-unity/build/depthai-core/libdepthai-core.so
#14 0x00007ffcef4a8faa in dai::XLinkConnection::close() (this=0x55556730b6e0) at /home/strazce/hax/depthai-unity/depthai-core/src/xlink/XLinkConnection.cpp:186
#15 0x00007ffcef2fbb21 in dai::DeviceBase::closeImpl() (this=0x55555a883480) at /home/strazce/hax/depthai-unity/depthai-core/src/device/DeviceBase.cpp:369
#16 0x00007ffcef2e8508 in dai::Device::closeImpl() (this=0x55555a883480) at /home/strazce/hax/depthai-unity/depthai-core/src/device/Device.cpp:82
#17 0x00007ffcef2fbacd in dai::DeviceBase::close() (this=0x55555a883480) at /home/strazce/hax/depthai-unity/depthai-core/src/device/DeviceBase.cpp:359
#18 0x00007ffdaab221c9 in DAICloseDevice(int) (deviceNum=0) at /home/strazce/hax/depthai-unity/src/device/DeviceManager.cpp:207
#19 0x0000000040762fb3 in  ()
#20 0x00007fffffffca00 in  ()
#21 0x000055555e72d010 in  ()
#22 0x00007fffffffc8b0 in  ()
#23 0x00007ffda9e2aa80 in  ()
#24 0x00007ffda9e2aa80 in  ()
#25 0x000055555caa4638 in  ()
#26 0x0000000040762f11 in  ()
#27 0x000055555b6b4f10 in  ()
#28 0x00007fffffffc6c0 in  ()
#29 0x00007fffffffc5f0 in  ()
#30 0x0000000000000000 in  ()

[gespona]

Thanks @themarpe ! Will give a try for sure and give feedback here … during my tests I was noticing some unstability when updated to latest main … so makes sense and I was about to check with you in the core part.

[gespona]

Hi @sliwowitz !, I was doing my own round of tests on Linux and I can confirm that I was not able to reproduce the issue anymore. Also I agree with you, the “fix” comes with recent core version bumps 😉 Closing the ticket 😉