Building OBS-studio on Xavier

It builds and installs but seems to crash on launch:

~/obs-studio/build$ obs
Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: /usr/share/obs/obs-studio/locale/en-US.ini
Attempted path: share/obs/obs-studio/locale.ini
Attempted path: /usr/share/obs/obs-studio/locale.ini
Attempted path: share/obs/obs-studio/themes/Dark.qss
Attempted path: /usr/share/obs/obs-studio/themes/Dark.qss
info: Physical Cores: 8, Logical Cores: 8
info: Physical Memory: 15822MB Total, 7786MB Free
info: Kernel Version: Linux 4.9.140-tegra
info: Distribution: "Ubuntu" "18.04"
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.19.6
info: Portable mode: false
Attempted path: share/obs/obs-studio/themes/Dark/no_sources.svg
Attempted path: /usr/share/obs/obs-studio/themes/Dark/no_sources.svg
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_destroyed()
QMetaObject::connectSlotsByName: No matching signal for on_actionGridMode_triggered()
QMetaObject::connectSlotsByName: No matching signal for on_program_customContextMenuRequested(QPoint)
info: OBS 24.0.3-517-gbc7946f8 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
	samples per sec: 44100
	speakers:        2
info: ---------------------------------
info: Initializing OpenGL...
Segmentation fault (core dumped)

any ideas?
Installed with:

sudo apt-get install \
        build-essential \
        checkinstall \
        cmake \
        git \
        libmbedtls-dev \
        libasound2-dev \
        libavcodec-dev \
        libavdevice-dev \
        libavfilter-dev \
        libavformat-dev \
        libavutil-dev \
        libcurl4-openssl-dev \
        libfdk-aac-dev \
        libfontconfig-dev \
        libfreetype6-dev \
        libgl1-mesa-dev \
        libjack-jackd2-dev \
        libjansson-dev \
        libluajit-5.1-dev \
        libpulse-dev \
        libqt5x11extras5-dev \
        libspeexdsp-dev \
        libswresample-dev \
        libswscale-dev \
        libudev-dev \
        libv4l-dev \
        libvlc-dev \
        libx11-dev \
        libx264-dev \
        libxcb-shm0-dev \
        libxcb-xinerama0-dev \
        libxcomposite-dev \
        libxinerama-dev \
        pkg-config \
        python3-dev \
        qtbase5-dev \
        libqt5svg5-dev \
        swig
git clone --recursive https://github.com/obsproject/obs-studio.git
cd obs-studio
mkdir build && cd build
cmake -DUNIX_STRUCTURE=1 -DCMAKE_INSTALL_PREFIX=/usr ..
make -j4
sudo checkinstall --default --pkgname=obs-studio --fstrans=no --backup=no \
       --pkgversion="$(date +%Y%m%d)-git" --deldoc=yes
~/obs-studio/build$ ls
cmake                CPackConfig.cmake        libGL.so                             plugins
CMakeCache.txt       CPackSourceConfig.cmake  libobs                               rundir
CMakeFiles           deps                     libobs-opengl                        UI
cmake_install.cmake  description-pak          Makefile
config               install_manifest.txt     obs-studio_20200224-git-1_arm64.deb

Maybe below link help

https://imgur.com/gallery/XqsTDRf

“strace” would produce an enormous amount of output, but the error is likely to show up in the last few hundred lines. I’m going to guess there is a mismatch with the OpenGL version, and an strace might provide more detail (as mentioned, you would go to the end of the log and work your way backwards to find the seg fault and a few lines prior to the seg fault). Example:

strace -oLog.txt /where/ever/it/is/obs

(if the application does not close upon seg fault, then close it yourself as fast as possible to avoid lots of log lines)

thank you for your suggestions;
It seems that even if it worked, the bandwidth wouldn’t allow high performance to take place for streaming [ as I tried from laptop and streaming to twitch and it was terrific.]
log attached
Log.txt (720 KB)

One of the down sides for embedded is the shared memory controller without dedicated video RAM, and this would slow down many operations, so I would not be surprised if there is a lack of throughput for streaming (unless quality is reduced). I would also not be surprised if the GPU is unavailable to OBS due to the integration of the GPU directly to the memory controller…most such applications require the PCI functions to find and use the GPU (though someone might be able to modify the source code, which would be a significant effort).

On that strace, did you have to manually stop the trace, or did the application self-terminate? I am also thinking perhaps there are other threads, and that strace with the “-f” option might be better:

strace -oLog.txt <b>-f</b> /where/ever/it/is/obs

In the particular log you had I see signal handler setups, but I didn’t see a definitive point of failure. In particular, I didn’t see a case insensitive “opengl” anywhere, and I think that this string would exist in any section of strace log near the error. The original error you gave had “Initializing OpenGL…”, and strace should have seen this going to stdout or stderr or stdlog if the log contained the error…search for “Initializing OpenGL” after tracing for parent and child threads under the “-f” option. Whatever follows the “Initializing OpenGL…” should be the actual error.

thank you for following up! it self-terminated shortly after the execution

Was there any note about the error near the end of the “strace -f” log?

it wont self terminate by now but some ubuntu errors pop up

sudo strace -oLog1.txt -f obs
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: /usr/share/obs/obs-studio/locale/en-US.ini
Attempted path: share/obs/obs-studio/locale.ini
Attempted path: /usr/share/obs/obs-studio/locale.ini
Attempted path: share/obs/obs-studio/themes/Dark.qss
Attempted path: /usr/share/obs/obs-studio/themes/Dark.qss
info: Physical Cores: 8, Logical Cores: 8
info: Physical Memory: 15822MB Total, 12754MB Free
info: Kernel Version: Linux 4.9.140-tegra
info: Distribution: "Ubuntu" "18.04"
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.19.6
info: Portable mode: false
Attempted path: share/obs/obs-studio/themes/Dark/no_sources.svg
Attempted path: /usr/share/obs/obs-studio/themes/Dark/no_sources.svg
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_destroyed()
QMetaObject::connectSlotsByName: No matching signal for on_actionGridMode_triggered()
QMetaObject::connectSlotsByName: No matching signal for on_program_customContextMenuRequested(QPoint)
info: OBS 24.0.3-517-gbc7946f8 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
	samples per sec: 44100
	speakers:        2
info: ---------------------------------
info: Initializing OpenGL...

Log1.txt (384 KB)

Unfortunately I don’t see the text “Initializing OpenGL”, which would occur in the trace log just prior to where the more useful information would occur. However, since this is OpenGL, perhaps I’m going about this wrong and instead we should use “ltrace” (traces library calls instead of system calls, and OpenGL is a user space library).

As an example, if you have glxgears:

ltrace -C -f -o library_calls.txt glxgears
ltrace -C -f -o library_calls.txt obs

library_calls.txt (601 KB)

Yes, this log contains the error. Here is the relevant excerpt from the end of the log, and everything up to this point works as intended without error:

22217 strlen("02:26:33 PM.414")                  = 15
22217 memcpy(0x7fd2e76be8, "02:26:33 PM.414", 15) = 0x7fd2e76be8
22217 operator new(unsigned long)(31, 30, 31, 0x55657485c8) = 0x55941267c0
22217 memcpy(0x55941267c0, "02:26:33 PM.414", 15) = 0x55941267c0
22217 memcpy(0x55941267cf, ": ", 2)              = 0x55941267cf
22217 strchr("Initializing OpenGL...", '\n')     = nil
22217 strlen("02:26:33 PM.414: ")                = 17
22217 std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)(0x7fd2e78da0, 0x55941267c0, 17, 0) = 0x7fd2e78da0
22217 strlen("Initializing OpenGL...")           = 22
22217 std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)(0x7fd2e78da0, 0x7fd2e76bf8, 22, 0x2d002e2e2e4c476e) = 0x7fd2e78da0
22217 std::ostream::put(char)(0x7fd2e78da0, 10, 0x60b50edd3967ab00, 8174) = 0x7fd2e78da0
22217 std::ostream::flush()(0x7fd2e78da0, 0, 0x60b50edd3967ab00, 0) = 0x7fd2e78da0
22217 operator delete(void*)(0x55941267c0, 0

Are you able to run this in a debugger? If so, then set a break at the location where it prints “Initializing OpenGL…”. Then single step in. You will go through the timestamp copies and prints. All it is doing is putting out a character, flushing the stream, and then deleting a memory address. Presumably the address delete is valid since it has a return value of “0”, but what follows in the next line of code will be the problem.

A series of “new”/“copy timestamp to”/“delete” operations occur on the variable, and each operation looks good with a delete ending in a return value of “0” (meaning the delete succeeded):

22217 operator delete(void*)(0x55941267c0, 0, 0x60b50edd3967ab00, 0) = 0

(this is valid cleanup, the “0” return means this did not cause the error)

This time, after a valid use of the variable and deallocating it, the SIGSEGV hits. I’m kind of surprised we didn’t see this in the strace and only saw this in the ltrace. Any SIGSEGV memory violation is something system calls should be able to point out, so I’m thinking we just were not doing the strace of the right thread or process. What this ltrace does is show that if you can find the line of code with “new” and “delete” with timestamp copies into it, then you know the next line after this the debugger will provide the “smoking gun evidence” of the actual failure.

Note that the PID of the timestamps being copied and printed is PID 22217, and that the actual SIGSEGV occurs in that PID. A number of child threads then report being killed due to this, and those have different PIDs, but the thread of origin for the failure is 22217. Why it seg faults right after a successful “delete” of a variable should be unrelated to the set/delete of the variable itself (and thus this is why you want to single step in from there).