Created attachment 819089 [details] asan_data.txt I get repeatable failures to start firefox (inbound, both last night and today) in an ASAN debug build due to a stack "overflow" in MarkConservatively(). It appears that MarkConservativelyAndSkipIon() is bumping the "begin" pointer (i) down to below the current start of the stack (and below stackMin).
$ ~/tools/llvm/build/Release+Asserts/bin/clang++ --version -> clang version 3.2 (trunk 163716) In case it's a compiler issue
Thanks for the report. (gdb) p stackMin $6 = (uintptr_t *) 0x7fffafff8de0 (gdb) p stackEnd $7 = (uintptr_t *) 0x7fffafff8e20 That's a stack size of 64 bytes, I'm not too familiar with the conservative scanner, is this expected? I also don't see any EnterIon or EnterBaseline frames in your stack trace. Do you know if we execute the JitActivationIterator loop in MarkRangeConservativelyAndSkipIon in this case? I will file a bug to add more assertions to MarkRangeConservativelyAndSkipIon, so that we can hopefully catch this in non-ASAN builds too, if there's really a bug here.
64 bytes is indeed much too small for a stack with 23 frames. Jan's point is also a good one--without any Ion frames on the stack, i should equal begin. I suspect that something is already corrupted by the time you get to this point in the code.
This appears to be a clang/llvm bug; I updated to the latest version listed on the MDN page for building ASAN (mine was much older) and the problem has gone away.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.