Segmentation fault in running vicalib

[inders]

I managed to setup Vicalib after some effort and some hacks to help resolve the Calibu unknown references issue. Now when I Run Vicalib on Realsense cameras it gives me segmentation fault and core dump after doing the calibration.

Any pointers would help.

[pedroperrusi]

Hello,

I've had the same issue on Vicalib without any changes to Calibu.
Vicalib seems to reach a segmentation fault right after writing its results to a file.

I can still exploit the calibration results, but it would be great to have an insight on what is going on.
The vicalib call I'm using doesn't hold anything special:
vicalib -cam realsense2:[id0=832112070477,id1=832112073478,size=1280x720,rgb=1,ir0=0,ir1=0,depth=0,emitter=0]// -grid_preset small -alsologtostderr true

And the gdb backtrace of the segmentation fault leads to:

Thread 90 "vicalib" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff8affd700 (LWP 10319)]
__GI___pthread_mutex_lock (mutex=0x8) at ../nptl/pthread_mutex_lock.c:65
65	../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6b08fa0 in __GI___pthread_mutex_lock (mutex=0x8) at ../nptl/pthread_mutex_lock.c:65
#1  0x00007ffff1175ba3 in __gthread_mutex_lock (__mutex=<optimized out>)
    at /usr/include/x86_64-linux-gnu/c++/7/bits/gthr-default.h:748
#2  0x00007ffff1175ba3 in __gthread_recursive_mutex_lock (__mutex=<optimized out>)
    at /usr/include/x86_64-linux-gnu/c++/7/bits/gthr-default.h:810
#3  0x00007ffff1175ba3 in std::recursive_mutex::lock() (this=<optimized out>)
    at /usr/include/c++/7/mutex:107
#4  0x00007ffff13a4a4e in std::lock_guard<std::recursive_mutex>::lock_guard(std::recursive_mutex&) (__m=..., this=<synthetic pointer>) at /usr/include/c++/7/bits/std_mutex.h:162
#5  0x00007ffff13a4a4e in el::base::RegisteredLoggers::get(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) (this=0x0, id="librealsense", forceCreation=false)
    at /home/mind02/git/librealsense/third-party/easyloggingpp/src/easylogging++.cc:1895
#6  0x00007ffff13a4ee1 in el::base::Writer::initializeLogger(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) (this=this@entry=0x7fff8afecf10, loggerId="librealsense", lookup=lookup@entry=true, needLock=needLock@entry=true)
    at /home/mind02/git/librealsense/third-party/easyloggingpp/src/easylogging++.cc:2578
#7  0x00007ffff13a52a5 in el::base::Writer::construct(int, char const*, ...) (this=this@entry=0x7fff8afecf10, count=count@entry=1, loggerIds=loggerIds@entry=0x7ffff145b70d "librealsense")
    at /home/mind02/git/librealsense/third-party/easyloggingpp/src/easylogging++.cc:2570
#8  0x00007ffff120c35f in librealsense::platform::v4l_uvc_device::poll() (this=this@entry=0x555556372220) at /home/mind02/git/librealsense/src/linux/backend-v4l2.cpp:882
#9  0x00007ffff120d2c8 in librealsense::platform::v4l_uvc_device::capture_loop() (this=0x555556372220)
    at /home/mind02/git/librealsense/src/linux/backend-v4l2.cpp:1231
#10 0x00007ffff42a166f in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff6b066db in start_thread (arg=0x7fff8affd700) at pthread_create.c:463
#12 0x00007ffff395e88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Maybe its an issue to post on HAL as well, but I would love to have your insight.