Bugzilla

Tail calls, per se, wouldn't account for this stack. When A tail calls B, that changes the stack "Q called A" with "Q called B", but every frame that can ever appear as the 'callee' of Q must lie within A's callee tree. It seems very unlikely that `libgallium_dri.so` is within `Mutex::Unlock`'s callee tree.

However, note that frames 8 through 15 are all inline frames: they're actually code that was inlined into frame 16, `firefox-bin!free`, at pc `0x0000561af413bd94`. That pc was recovered by stack scanning: the unwinder has given up on CFI and frame pointers, and is simply guessing that any block of bytes that happens to form a code address might be a return address, and reporting it as a frame. It could be just garbage left on the stack from prior calls. That would account for frames 8 through 16.

Then, having frame 17 in `libEGL_mesa.so.0` call frame 7 in `libgallium_dri.so` is less surprising.

Tail calls, per se, wouldn't account for this stack. When A tail calls B, that changes the stack "Q called A" into "Q called B", but every frame that can ever appear as the 'callee' of Q must lie within A's callee tree. It seems very unlikely that `libgallium_dri.so` is within `Mutex::Unlock`'s callee tree.

However, note that frames 8 through 15 are all inline frames: they're actually code that was inlined into frame 16, `firefox-bin!free`, at pc `0x0000561af413bd94`. That pc was recovered by stack scanning: the unwinder has given up on CFI and frame pointers, and is simply guessing that any block of bytes that happens to form a code address might be a return address, and reporting it as a frame. It could be just garbage left on the stack from prior calls. That would account for frames 8 through 16.

Then, having frame 17 in `libEGL_mesa.so.0` call frame 7 in `libgallium_dri.so` is less surprising.