(and RE this from comment 21): (In reply to Christian Holler (:decoder) from comment #21) > In general for OOMs, I would recommend disabling the test with TSan (TSan consumes more memory than normal). > > However, this specific instance looks like a large allocation of some sort (271579377590272 bytes would fail no matter what). IT might be worth checking where this allocation is coming from and fixing this at the source. This should also OOM or crash regular builds. If this allocation is from **TSAN itself** (as part of its race detection bookkeeping), as I suspect it is, then that would explain why it doesn't happen in regular builds. decoder, see comment 59 and this comment... Do you have any additional insight/suggestions here about how to reduce TSAN's overhead? (It is interesting that this seems to be specific to reftest runs. Maybe there's some sort of cumulative overhead that TSAN builds up, with each `drawWindow` call... I wonder if we might be able to avoid this intermittent to some extent by reducing the number of reftest tests we run in each task/bucket? (i.e. increasing our number of TSAN reftest buckets)
Bug 1770595 Comment 60 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(and RE this from comment 21): (In reply to Christian Holler (:decoder) from comment #21) > In general for OOMs, I would recommend disabling the test with TSan (TSan consumes more memory than normal). > > However, this specific instance looks like a large allocation of some sort (271579377590272 bytes would fail no matter what). IT might be worth checking where this allocation is coming from and fixing this at the source. This should also OOM or crash regular builds. If this allocation is from **TSAN itself** (as part of its race detection bookkeeping), as I suspect it is, then that would explain why it doesn't happen in regular builds. decoder, see comment 59 and this comment... Do you have any additional insight/suggestions here about how to reduce TSAN's overhead? (It is interesting that this seems to be specific to reftest runs -- nearly all of the failures here are reftests. Maybe there's some sort of cumulative overhead that TSAN builds up, with each `drawWindow` call... I wonder if we might be able to avoid this intermittent to some extent by reducing the number of reftest tests we run in each task/bucket? (i.e. increasing our number of TSAN reftest buckets)