tracy-capture and connected client app hangs before shutdown

[snaulX]

I met the bug, when I run my app, built on CI server, and connect tracy-capture to it - before shutting down, both app and tracy are hanging.
What I have found by myself:

• Tracy server was handling QuerySourceCode commands differently for files that are not valid. In app binaries, built on server, file names were taken from server paths, but it's not exists locally, so tracy claims those files as invalid.
• Due to different QuerySourceCode handling behavior for the invalid files, TracyWorker::m_sourceCodeQuery had not been cleared before termination. But in case of termination, tracy checked this variable on emptiness to understand, has it some work to do - and in case if yes, it continues its main loop (TracyWorker.cpp, 2852 in 0.11.1 version). It causes infinite waiting, because m_sourceCodeQuery will not be cleared in any case further.
• Client app waits until tracy completes its shutdown before shutdown itself. So it's hanging with tracy too.
• So if I remove !m_sourceCodeQuery.empty() check, everything will be fixed.

What's there incorrect and how this suppose to work normally? Does this check really needs there?

[wolfpld]

The client should respond that source files are not available, which should eventually empty the m_sourceCodeQuery array, allowing termination of profiling.

[snaulX]

I see, that client should send a QueueType::AckSourceCodeNotAvailable in Profiler::HandleSourceCodeQuery to erase elements from m_sourceCodeQuery. But this function called only from Profiler::HandleSymbolQueueItem that is inside in #ifdef TRACY_HAS_CALLSTACK which is disabled in my app. What's going wrong there?

[wolfpld]

Why is it disabled?

[snaulX]

I turn it off, because in most cases I don't need it and it produces additional load. This is optional, isn't it?

[wolfpld]

Technically it is, but by disabling it you hit code paths that are not really tested or supported, as you have noticed.