Orbit crashed when trying to connect to QT application about orbit

[alexkalmuk]

For the CLI version, it doesn't crash and even collects some events, but it seems that the symbols are loaded only from ELF file but not from the shared libraries. I'll try to dig a bit deeper into that issue with the crash.

[florian-kuebler]

Interesting. We used to profile Orbit itself with Orbit (also quite recently), so I am a bit surprised. I remember some issues shared libraries, when passing the wrong flags to the dlopen call, but not sure if this is relevant.

I assume the crash does manifest in a stall in a non-debug build? In general, would be interesting to see what the other threads are doing.

We've also seen issues in the past, when the target has too many modules. You might want to try disabling auto-symbol loading (start with --auto_symbol_loading=false) and load symbols manually.

it seems that the symbols are loaded only from ELF file but not from the shared libraries.

It should be possible to open the capture in the UI version afterwards and then load the symbols (right-click on the module, in case auto-symbol loading does not work).

[alexkalmuk]

I remember some issues shared libraries, when passing the wrong flags to the dlopen call, but not sure if this is relevant.

It's hard to say so far, but at least it seems that the deadlock happens on different libraries at different moments of time.

I assume the crash does manifest in a stall in a non-debug build?

I'm using debug build: -DCMAKE_BUILD_TYPE=Debug.

In general, would be interesting to see what the other threads are doing.

Agree, I'll take a look into gdb in the evening. After brief examination yesterday, it seems that Orbit allocates one thread from thread pool per one shared library to load symbols, so these threads are running in parallel. And, at some moment, the deadlock happens. But I'll double check and see at which states all the threads are.

[alexkalmuk]

I'm still debugging/reading the code. That's something weird around the mutex in ScheduleAfterIfSuccess (Executor.h)
But here, as I promised, are threads and stack traces (the current thread has ID 32):
threads_bt.txt
threads_info.txt

P.S.
By the way, it seems that this deadlock verification is only enabled in debug version of absl, so I'm not sure if this issue is reproduced in the Release version.