You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dart:io's exit call's libc's exit without first calling Dart_Cleanup. This can cause TSAN to complain about leaks of VM thread pool threads. Ideally we would inform TSAN that when we exit this way we don't care about leaks (and likewise for LSAN), but there doesn't appear to be a way to set TSAN's report_thread_leaks at runtime. We don't want completely ignore thread leak reportings because it is useful when we shutdown gracefully (main isolate completes its message and has no open receive ports).
The text was updated successfully, but these errors were encountered:
rmacnak-google
added
the
area-vm
Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
label
May 7, 2020
The puzzling thing is that global C++ state should be treated as strong roots by the leak sanitizer and therefore everything (transitively) reachable from it should not be considered as leaks. See lsan design doc
So I would assume the global thread pool, various global mutexes/monitors and global lists are treated as roots. One of those roots is a global list of isolate groups, each of which has a list of isolates. So all those resources should not be considered as leaks.
Mostly interesting on Mac, where ASAN does not include LSAN.
Bug: #41811
Change-Id: Icbbe57946a6d3b3406a9e3a6541b6c4958cbfa91
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147685
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
dart:io's exit call's libc's exit without first calling Dart_Cleanup. This can cause TSAN to complain about leaks of VM thread pool threads. Ideally we would inform TSAN that when we exit this way we don't care about leaks (and likewise for LSAN), but there doesn't appear to be a way to set TSAN's report_thread_leaks at runtime. We don't want completely ignore thread leak reportings because it is useful when we shutdown gracefully (main isolate completes its message and has no open receive ports).
The text was updated successfully, but these errors were encountered: