AsanThread::Destroy implementation expected to be called on
child thread.
I missed authors concern regarding this reviewing D95184.
Differential D95731
[asan] Fix pthread_create interceptor vitalybuka on Jan 30 2021, 12:44 AM. Authored by
Details
AsanThread::Destroy implementation expected to be called on I missed authors concern regarding this reviewing D95184.
Diff Detail
Event TimelineComment Actions Thanks for catching this. Did this break something somewhere? I didn't see any emails about breaking CI. I've left some minor comments in the review but overall the approach seems good to me.
Comment Actions It fails many_threads_detach.cpp on my workstation. Probably bots have higher thread limits.
Comment Actions Thanks for working on this. The new approach LGTM apart from calling malloc_storage().CommitBack();. I've left a comment on this. I suspect it's probably okay but I wanted to bring this up before we land this.
|
@vitalybuka Should malloc_storage().CommitBack(); be guarded by `was_running too?
I'm not very familiar with this part of ASan's allocator but it looks like malloc_storage() is returning some kind of thread local cache for the quarantine and the primary allocator. I'm guessing that this cache would not be used if was_running is false because we never started the thread and so no allocations could have occurred. That would imply that technically calling malloc_storage().CommitBack(); when was_running is false is unnecessary.
However, for simplicity and to avoid creating an avenue for future bugs calling malloc_storage().CommitBack(); unguarded is probably better provided we are sure it's safe to do this for storage for a thread that was never started. Are we sure it's safe?