bryancall commented on PR #13683: URL: https://github.com/apache/trafficserver/pull/13683#issuecomment-5683346119
Both findings from the Copilot review are addressed. The JIT gating one had a thread and is answered and resolved there; this covers the suppressed one, which had no thread to reply in. **Multithreaded coverage.** You were right, and the gap was mine: I had written exactly this test and then filed it with the wrong change. It sat on the follow-up branch that makes the pcre2 contexts process-wide, because that is where it first landed. The property it guards is introduced *here*, by resolving the JIT stack per thread through a callback, so here is where it belongs. Moved in c4cdac1110. Eight threads match on one `Regex`, half of them through a single `RegexMatchContext` built before the workers start. That is deliberate and it is the shape your comment asked for: an implementation that cached one stack in the context, or handed the same stack to every thread, passes a test that gives each thread its own context and corrupts this one. The start gate is a mutex and condition variable rather than `std::latch`, which says it more directly but is not in libstdc++ before 11 and the CentOS lane runs devtoolset-10. Verified on Fedora 44, gcc 16.2.1, PCRE2 10.47: - `[Regex]` under ThreadSanitizer: 388 assertions in 21 cases, no warnings. `[threads]` alone is also clean. - `[Regex]` under AddressSanitizer with UBSan: same counts, clean. - `regex_remap` autest executes 14 runs with `TS_HAS_PCRE2_JIT 1`; `diags.log` carries both `-46` and `-47`. -- 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]
