There was a concurrency issue `WasmEngine::EnterDebuggingForIsolate`
which gets fixed by this CL. When multiple isolates entered debugging
concurrently, then only the first CL that changes the debug state of
a NativeModule would remove all compiled code from the NativeModule.
However, changing the debug state and removing the compiled code would
not happen atomically inside a lock. Instead, first the debug state
gets changed inside the lock, and then the compiled code gets removed
outside the lock. The concurrency issue is now the following.
Assume isolate A enters debugging. It takes the lock, and then changes
the debug state. As it changes the debugging state, it is the task of
isolate A to delete all code. Concurrently isolate B also enters
debugging. It sees that the debug state is already changed to debug
state and therefore just continues execution without removing code
first. In the following execution of isolate B non-debug code may get
executed if isolate A is slow with removing the code.
This CL fixes the issue by adding a filter to `RemoveCompiledCode`, and
then letting all isolates remove compiled code according to the filter.
This means that isolate B would also iterate over all the code and
remove all functions which are non-debug functions. This guarantees
that isolate B does not execute non-debug code that existed before
isolate B entered debugging.
R=clemensb@chromium.org
Bug: v8:13541
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Change-Id: If688c7f9b15f78e6cd6898123a321e577d32365f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111524
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84919}
51bdde997e