failing to unwind sadness_generator::raise_stackoverflow::recurse on x64 macos

[Gankra]

Found while testing out minidump-pipeline on x64 macos

Here's a dump of all the relevant info, the most interesting/pertinent being that the stack memory for the stack is a clearly cursed address called 0xdeaddead?!

unwinding sadness_generator::raise_stack_overflow::recurse
    [unwind_frame {"fname": "sadness_generator::raise_stack_overflow::recurse", "idx": "0"}]
        trying cfi
        found symbols for address, searching for cfi entries
        trying STACK CFI exprs
          .cfa: $rbp 16 + $rbp: .cfa -16 + ^ .ra: .cfa -8 + ^ $rbx: .cfa -24 + ^
        STACK CFI parse successful
        STACK CFI seems reasonable, evaluating
        successfully evaluated .cfa (frame address)
        trying frame pointer
        trying scan
    finished stack unwind of thread 4355 main

thread[0]
MINIDUMP_THREAD
  thread_id                   = 0x1103
  suspend_count               = 0
  priority_class              = 0x0
  priority                    = 0x0
  teb                         = 0x0
  stack.start_of_memory_range = 0xdeaddead
  stack.memory.data_size      = 0x10
  stack.memory.rva            = 0x294
  thread_context.data_size    = 0x4d0
  thread_context.rva          = 0x2a4

region[0]
MINIDUMP_MEMORY_DESCRIPTOR
  start_of_memory_range = 0xdeaddead
  memory.data_size      = 0x10
  memory.rva            = 0x294
Memory
    00000000: ad de ad de 00 00 00 00 ad de ad de 00 00 00 00 ................

region[1]

...did we trigger some weird macos safety protection system? or is sadness_generator just doing something wonky?

[Gankra]

the actual unwind was

.cfa: $rbp 16 +
.ra: .cfa -8 + ^      <---- dies

rbp: 0x7ffeeaa15130
rsp: 0x7ffeeaa14f10

Those seem plausible, but all the mapped memory pages (other than 0xdeaddead) are 0x70000*******, so we definitely don't have that memory (so not #637).

[Gankra]

this is https://github.com/rust-minidump/minidump-writer/blob/cc93bd26b1a4dce800e3dc8f7ab90553a59e835a/src/mac/streams/thread_list.rs#L72-L100

[Gankra]

are we just failing to walk the stackpointer back from a guardpage of some kind?

[luser]

This is a stack overflow in pure Rust code, right? So it'd be hitting the guard page that std adds there.