Interesting and puzzling! As a quick test, I deactivated the leaf-frame-skipping in the stack walker (by making [`FrameSkipper::ShouldSkipPC`](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/mozglue/misc/StackWalk.cpp#75-85) always return false), and I didn't notice differences: - opt, debug, with normal frame-skipping: https://share.firefox.dev/3xQwMaS - opt, debug, no frame-skipping: https://share.firefox.dev/2W2dRga - -O1, no-debug, no frame-skipping: https://share.firefox.dev/3ABVcXo I tried -O0, but (re)symbolication timed out, so that didn't help. Looking at the code, I would expect inverted call stacks to **only** start from `replace_malloc` and other such functions that intercept allocations and add markers for them, or maybe one of the sub-functions on the way to the stack walker. On Windows the actual sequence of calls should be: - function_that_calls_malloc - `replace_malloc` in memory_hooks.cpp - `gMallocTable.malloc` calling the "real" malloc - `AllocCallback` - `profiler_add_native_allocation_marker` - `profiler_add_marker` - `AddMarkerToBuffer` - `profiler_capture_backtrace_into` - `Registers::SyncPopulate` - `RtlCaptureContext` win32 function retrieving the registers in the context of the **caller** - `DoSyncSample` - `DoSharedSample` - `DoNativeBacktrace` - `DoMozStackWalkBacktrace` - StackWalkCallback, first records the leaf function as captured by `RtlCaptureContext` above - `MozStackWalkThread` native stack-walker, called in a loop with resume points (mostly past JIT code) One worry is that the context captured by `RtlCaptureContext` may be disconnected from the stack-walking happening after that. We already have bug 1695618 to look into this. But note that it's nevertheless always stored as the leaf frame, so I would expect the most-immediate non-inline caller to be present. I think the next step will be to try and debug this, e.g.: debug-break on the stack-walking function, and compare the captured stack with the debugger's view of the stack... Other suggestions welcome.
Bug 1725057 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Interesting and puzzling! As a quick test, I deactivated the leaf-frame-skipping in the stack walker (by making [`FrameSkipper::ShouldSkipPC`](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/mozglue/misc/StackWalk.cpp#75-85) always return false), and I didn't notice differences: - opt, debug, with normal frame-skipping: https://share.firefox.dev/3xQwMaS - opt, debug, no frame-skipping: https://share.firefox.dev/2W2dRga - -O1, no-debug, no frame-skipping: https://share.firefox.dev/3ABVcXo I tried -O0, but (re)symbolication timed out, so that didn't help. Looking at the code, I would expect inverted call stacks to **only** start from `replace_malloc` and other such functions that intercept allocations and add markers for them, or maybe one of the sub-functions on the way to the stack walker. On Windows the actual sequence of calls should be: - function_that_calls_malloc - `replace_malloc` in memory_hooks.cpp - `gMallocTable.malloc` calling the "real" malloc - `AllocCallback` - `profiler_add_native_allocation_marker` - `profiler_add_marker` - `AddMarkerToBuffer` - `profiler_capture_backtrace_into` - `Registers::SyncPopulate` - `RtlCaptureContext` win32 function retrieving the registers in the context of the **caller** - `DoSyncSample` - `DoSharedSample` - `DoNativeBacktrace` - `DoMozStackWalkBacktrace` - StackWalkCallback, first records the leaf function as captured by `RtlCaptureContext` above - `MozStackWalkThread` native stack-walker, called in a loop with resume points (mostly past JIT code) One worry is that the context captured by `RtlCaptureContext` may be disconnected from the stack-walking happening after that. We already have bug 1714501 to look into this. But note that it's nevertheless always stored as the leaf frame, so I would expect the most-immediate non-inline caller to be present. I think the next step will be to try and debug this, e.g.: debug-break on the stack-walking function, and compare the captured stack with the debugger's view of the stack... Other suggestions welcome.
Interesting and puzzling! As a quick test, I deactivated the leaf-frame-skipping in the stack walker (by making [`FrameSkipper::ShouldSkipPC`](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/mozglue/misc/StackWalk.cpp#75-85) always return false), and I didn't notice differences: - opt, debug, with normal frame-skipping: https://share.firefox.dev/3xQwMaS - opt, debug, no frame-skipping: https://share.firefox.dev/2W2dRga - -O1, no-debug, no frame-skipping: https://share.firefox.dev/3ABVcXo I tried -O0, but (re)symbolication timed out, so that didn't help. Looking at the code, I would expect inverted call stacks to **only** start from `replace_malloc` and other such functions that intercept allocations and add markers for them, or maybe one of the sub-functions on the way to the stack walker. On Windows the actual sequence of calls should be: - function_that_calls_malloc - `replace_malloc` in memory_hooks.cpp - `gMallocTable.malloc` calling the "real" malloc - `AllocCallback` - `profiler_add_native_allocation_marker` - `profiler_add_marker` - `AddMarkerToBuffer` - `profiler_capture_backtrace_into` - `Registers::SyncPopulate` - `RtlCaptureContext` win32 function retrieving the registers in the context of the **caller** - `DoSyncSample` - `DoSharedSample` - `DoNativeBacktrace` - `DoMozStackWalkBacktrace` - StackWalkCallback, first records the leaf function as captured by `RtlCaptureContext` above - `MozStackWalkThread` native stack-walker, called in a loop with resume points (mostly past JIT code) One worry is that the context captured by `RtlCaptureContext` may be disconnected from the stack-walking happening after that. We already have bug 1714501 to look into this. But note that it's nevertheless always stored as the leaf frame, so I would expect the most-immediate non-inline caller to be present. I think the next step will be to try and debug this, e.g.: debug-break on the stack-walking function, and compare the captured stack with the debugger's view of the stack... Other suggestions welcome.