pisarev commented on issue #727: URL: https://github.com/apache/tvm-ffi/issues/727#issuecomment-5533260472
Thanks. I agree that one mutex must cover every DbgHelp call made by `TVMFFIBacktrace`. That fixes the reported race between concurrent `TVMFFIBacktrace` calls. I think the patch still needs a private session handle and initialization that is retained after it succeeds. DbgHelp locates a caller's symbol state through the `hProcess` value passed to `SymInitialize`. Microsoft's [`SymInitialize` documentation](https://learn.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-syminitialize) says this value must be unique to avoid sharing a session with another component. It also says not to use the value returned by `GetCurrentProcess()`. I tested the reduced design in an actual `tvm_ffi.dll` build. In a single-threaded test, the lock-only build destroyed a DbgHelp session that the host had initialized first. The host's next symbol lookup failed with `ERROR_INVALID_HANDLE` (6). The reduced build kept both sessions usable in either initialization order. In a separate 12-frame test, the current, lock-only, and reduced builds produced the same 692-byte backtrace, byte for byte. Every frame contained its function name, file, and line. The reduced patch contains: - one mutex around all DbgHelp calls made by `tvm_ffi`; - one duplicated process handle, private to `tvm_ffi`, passed to those calls; - lazy initialization retained after success, with no `SymCleanup` after each backtrace. This version omits the re-entry guard, the throwing `call_once` helper, and `SYMOPT_DEFERRED_LOADS`. Keeping the session also avoids repeated module enumeration under the mutex. In our six runs with 8 threads and 200 calls per thread, lock-only took 81-97 seconds. The reduced build took less than 0.4 seconds in each of eight runs of the same workload. The mutex serializes only DbgHelp calls made inside `tvm_ffi`. It cannot serialize calls from an unrelated DLL. Would this reduced version be acceptable for a pull request? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
