pisarev commented on issue #727:
URL: https://github.com/apache/tvm-ffi/issues/727#issuecomment-5502658822
## Whether the race is removed, or merely made rare
Crash counting cannot answer that: a finite failure-free series is consistent
with both. So the question was settled by measuring the invariant that is
violated rather than the symptom that follows from it.
Two extra builds were made from the unmodified file, each with a counter
around
the DbgHelp region recording how many threads are inside it at the same
moment.
Two details of that counter matter and are easy to get wrong. It keeps a
`thread_local` depth beside the shared count, because `StackWalk64` invokes
`SymFunctionTableAccess64` and `SymGetModuleBase64` as callbacks nested on
the
same thread — a plain counter reads that as overlap and slanders every build
equally. And the first thread in waits briefly, once, for a second to arrive,
with a timeout; without that the threads can simply miss each other and a
serialized build is indistinguishable from an unserialized one that got
lucky.
16 threads, 500 calls each, 10 independent runs of each build:
build crashed max threads inside DbgHelp
lifetime only, no lock 0 of 10 16 16 16 16 16 16 16 16 16 16
lock + lifetime 0 of 10 1 1 1 1 1 1 1 1 1 1
Both columns of crashes are zero. The right-hand column is the answer.
Dropping the per-call `SymInitialize`/`SymCleanup` without a lock leaves
**all
sixteen threads inside DbgHelp at once, in every run, while the run reports
success**. It does not remove the race. It removes the collision that made
the
race visible — the teardown of the symbol tables under a thread that is
walking
them — and leaves the rest of the contract violated exactly as before.
One further run of that build, outside the series above, did die with
`0xC0000374` (heap corruption), so the violation is not only demonstrable but
occasionally still fatal.
The instrumentation is test-only and is not part of the proposed patch.
--
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]
