New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gc_marker.cc ASSERT failure #26706
Comments
Oh, this is an obvious bug, sorry about this. It's a race: one thread manages to reach an increment marked We should just remove the assertion. I originally removed it precisely because it is very hard to make it work in the current setup and then I reinstated it thinking it's fine to do after the barrier - but missed this case. barrier_->Sync();
ASSERT(AtomicOperations::LoadRelaxed(num_busy_) == 0); // (1)
// Check if we have any pending properties with marked keys.
// Those might have been marked by another marker.
more_to_mark = visitor.ProcessPendingWeakProperties();
if (more_to_mark) {
// We have more work to do. Notify others.
AtomicOperations::FetchAndIncrement(num_busy_); // (2)
}
// Wait for all other markers to finish processing their pending
// weak properties and decide if they need to continue marking.
// Caveat: we need two barriers here to make this decision in lock step
// between all markers and the main thread.
barrier_->Sync(); alternatively we can do: barrier_->Sync();
#if defined(DEBUG)
ASSERT(AtomicOperations::LoadRelaxed(num_busy_) == 0); // (1)
barrier->Sync();
#endif (main thread would need to be fixed accordingly). |
Hit it again:
|
This should fix it |
Adjusted the assertion to avoid data-race in 59e67cc. |
https://build.chromium.org/p/client.dart/builders/vm-linux-debug-x64-be/builds/10042/steps/checked%20vm%20tests/logs/stdio
The text was updated successfully, but these errors were encountered: