Closed sliwowitz closed 1 year ago
I'm facing the same issue with ubuntu 20.04 and unity 2021.2.7f
I can't reproduce it now. Ubuntu 22.10 with Unity 2022.2.1f1 or 2012.3.16f1 LTS - same as https://github.com/luxonis/depthai-unity/issues/9#issuecomment-1380313563
Thanks for your patience and support @sliwowitz !
I'm trying to run
depthai-unity
on Ubuntu with an OAK-D-Lite sensor. If I build the Playground scene, it dies when attempting to switch (sub)scenes by the arrow buttons, or the menu button.I managed to build the shared libraries so that Unity can use them, the project loads fine and mostly works in the Editor (except for a possibly different issue #9). At first, this bug consistently happened to me in the Editor too. Now I can reproduce it in the Editor just occasionally, but it still happens every time if I run the built binary.
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
Steps to reproduce:
0. Get the code
I'm using the
beta
branch.1. Build
depthai-core
2. Build
depthai-unity
shared library.so
Add
SHARED
keyword to theadd_library
directive inCMakeLists.txt
, line 35, then run:(BTW, even with these settings,
libdepthai-resources.a
is still built as a static library)3. Copy the library to the project plugin folder
4. Convert the
loader.mp4
video towebm
Unity complained about the loader.mp4 file
Error while reading movie: ....../Playground/loader.mp4
andVideoClip import error for......./loader.mp4. On Linux, import of VP8 movies (.webm extension) is supported.
So I converted the mp4 to webm using ffmpeg. The video plays fine in the editor. The command wasffmpeg -i loader.mp4 -c:v libvpx -crf 30 -b:v 0 -b:a 128k -c:a libvorbis loader.webm
.5. Open the project
loader.mp4
withloader.webm
in Playground Menu -> Loader ObjectCPU time limit exceeded (core dumped)
6. Run in
gdb
SIGXCPU
is also thrown if a thread dies andgdb
makes a pause - other threads are killed withSIGXCPU
after you try to continue, there's also a bunch of uninterestingSIGPWR
thrown, so first disable the SIGXCPU and SIGPWR traps before we get near the crash we want to see.Go to where the build lives, run
gdb ./Build1.x86_64
Let the scene run, and just before you decide to switch scenes, go back to
gdb
, and pressCtrl+C
Switch back to the scene, click the menu button or the arrows. The scene hangs, and
gdb
has a stack trace ready: