It seems like we've been lead on a wild goose chase by a symbol dumping bug. I've opened one of the minidumps and looked at the disassembly and found that the address does not correspond to the functions that appear on the stack on crash reports. It's in `_NS_NewLocalFileWithCFURL` which is in a totally different place. The remaining part of the stack is also most likely wrong and this explains why the following frames are found by stack scanning. It's not the stack that's corrupted, it's the first frame that's being mis-identified. The issue boils down to the .sym file lacking an entry for `_NS_NewLocalFileWithCFURL` which leads the stack walker to find the nearest symbol which often turns up as `std::__1::__sift_up<T>`. Once there it uses CFI information from that symbol, can't find the pointer to the previous frame and resorts to stack scanning. I will try to extract the real stack trace and attach it ASAP.
Bug 1654335 Comment 55 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It seems like we've been lead on a wild goose chase by a symbol dumping bug. I've opened one of the minidumps and looked at the disassembly and found that the address does not correspond to the functions that appear on the stack on crash reports. It's in `NS_NewLocalFileWithCFURL` which is in a totally different place. The remaining part of the stack is also most likely wrong and this explains why the following frames are found by stack scanning. It's not the stack that's corrupted, it's the first frame that's being mis-identified. The issue boils down to the .sym file lacking an entry for `NS_NewLocalFileWithCFURL` which leads the stack walker to find the nearest symbol which often turns up as `std::__1::__sift_up<T>`. Once there it uses CFI information from that symbol, can't find the pointer to the previous frame and resorts to stack scanning. I will try to extract the real stack trace and attach it ASAP.