Closed trindadegm closed 5 months ago
You'll want the manual lifetime compile time feature, I think, which became non-default in 0.17. The Tracy manual should have some notes about this too.
Thank you for the advice, and sorry for the delayed response. Adding "manual-lifetime" and "delayed-init" solved my problem. I had first tried to just add the "manual-lifetime" feature but when it feailed to compile I saw that it implied "delayed-init", so I added that as well. Now I can use version 0.17 with no problems.
I updated the library from 0.16.5 to 17.0 and got a problem in an application of mine. The Rust portion of the code is a DLL invoked from a C++ application. The C++ application is not the one being profiled, only some threads and some function calls on the Rust side. Things were working fine, and they still are, to an extent.
The Rust app is loaded at runtime, a thread is spun from C++ which will run a loop in the Rust library. There is some message passing from Rust/C++, both ways, so sometimes the C++ thread will get into Rust code and vice versa. The Rust lib has tracy_client, but the C++ portion has no idea tracy exists. I imagined there wouldn't be much trouble with it. However, when the app is shutting down, the Rust portion of the code starts to shutdown, the thread that runs Rust code is joined from C++ side, and the DLL should be unloaded. However, the process never finishes.
I could not replicate this yet on another project, by just using a DLL, though.
Pulling it on the debugger while the problem was happening, I saw some thread was stuck at
TracyThread.hpp
, line 46, on aWaitForSingleObject
call, on theThread
destructor.I don't know if it is a problem with this library, or the way I'm using. I'll try to replicate this problem but if any of you can help me identify what the problem might be I'd be grateful.
I'm using these features: