error: memory read failed for 0x0, no stack

Xcode debug my app, I find some thread no stack, only 0x00000000 (but not crash).

Stack info:

error: memory read failed for 0x0

I think stack overflow, so I try use tool "Address Sanitizer", but not found too.

Why is this happening, xcode no stack?


Screenshot url:

https://i.stack.imgur.com/N0wGW.png

Replies

Crashes like this are usually the result of your smashing your stack so badly that returning from a function fills the registers with garbage, which prevents the debugger from backtrace your thread.

I notice you managed to catch this crash in the debugger. How reproducible is it? Can you reproduce it outside of the debugger, by running your app from the Finder / Home screen?

Also, is this a Mac app? Or for iOS or one of its derivatives? And if it’s the latter, is this crashing in the simulator? Or on the device?

Oh, and is this Swift? Or Objective-C? Or something else?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is the ios app, real machine iphone device debugging, this phenomenon can basically be reproduced. In this case, this is not a crash, it is captured by breakpoint debugging when pause.

But the app version on the appstore has a similar no-stack crash.

This is a program developed by objective-c.

Thanks for all the answers.

But the app version on the appstore has a similar no-stack crash.

Can you post a crash report for that?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Since some sensitive information may be involved, the crash information I sent to your mailbox … separately, the subject of the email is "error: memory read failed for 0x0, no stack", please see the attachment, thank you.

Since some sensitive information may be involved, the crash information I sent to your mailbox

OK, that’s cool.

I took a look at that report and I’m not sure it’s an Apple crash report. At the top I see this:

CrashReporter Key:   TODO

and I’d expect that field to be filled out. Also:

  • At the end of the report there’s a whole bunch of stuff that I wouldn’t expect to see in an Apple crash report.

  • There’s some oddities in the way that each stack frame is rendered.

Are you using a third-party crash reporter here? If so, please remove that, reproduce the problem, grab the Apple crash report, and post that (well, email it to me :-).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your timely feedback, indeed, using an unofficial report. I have re-issued Apple's official crash report to your email by replying to the email.

Thanks for sending me an Apple crash report. Let’s take a look at it. To start, here’s the exception information:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Triggered by Thread:  68

This is a memory access exception at 0. Now let’s look at the crashing thread:

Thread 68 Crashed:

Thread 69:

Oi vey! no backtrace. Now let’s look at the state of the CPU ta the time of the crash.

Thread 68 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000100   x3: 0x000000000091ce30
    x4: 0x0000000000002060   x5: 0x0000000000000060   x6: 0x0000000000000000   x7: 0x0000000000000000
    x8: 0xffffffffffffffff   x9: 0x0000000000000000  x10: 0x0000000000000003  x11: 0x0000020000000303
   x12: 0x0000000000000000  x13: 0x0000000000000300  x14: 0x0000010000000100  x15: 0x0000000000000000
   x16: 0x000000000000012d  x17: 0x0000000000000000  x18: 0x0000000000000000  x19: 0x0000000000000000
   x20: 0x0000000000000000  x21: 0x0000000000000000  x22: 0x0000000000000000  x23: 0x0000000000000000
   x24: 0x0000000000000000  x25: 0x0000000000000000  x26: 0x0000000000000000  x27: 0x0000000106be31b8
   x28: 0x000000011bdd6060   fp: 0x0000000000000000   lr: 0x0000000000000000
    sp: 0x000000017162eea0   pc: 0x0000000000000000 cpsr: 0x60000000

As you can see, most of the CPU registers have been cleared. That’s not good. Specifically:

  • pc
    — This is the immediate cause of the crash; you’ve jumped to address 0 and have thus crashed trying to fetch instructions from that unmapped memory.
  • lr
    — Normally a jump like this leaves the return address in this register, and the crash reporter can start a backtrace based on that. However, in this case the value is also 0.

It’s hard to say how you got into this state, but the usual reason for this sort of thing is that you’ve smashed your stack horribly, and thus crashed after restoring the CPU state from that stack.

As to what to do now, I recommend that you focus on your efforts on

sp
, which looks like a valid stack pointer. With a bit of grovelling through that stack you should be able to build a manual backtrace.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Found in the appstore online version, this no-stack crash occurs on iOS10.x.

Stack traceability seems to only get the memory address of lr, but can not get the value of lr, this is my question?

Also, is there any way to find out where the messy stack and registers are caused?

Also, is there any way to find out where the messy stack and registers are caused?

Well, that’s kinda the point of this investigation.

Stack traceability seems to only get the memory address of

lr
, but can not get the value of
lr
, this is my question?

Right, the fact that

lr
is 0 is what’s preventing the standard backtrace mechanisms from working. That means you’ll need to actually look at the stack to see what you can see. Keep your eye out for two things:
  • Return addresses

  • Obvious signs of stack corruption, such as large chunks of zeroes, or text, or seemingly random values

If you find one return address you can generally backtrace from there by disassembling the function whose return address you have and working out where it stashes

lr
on entry.

The alternative here is to approach this problem from the other direction. Given that you can reproduce the problem, you can look at the code running up to the point where the problem occurs, using breakpoints and stepping to see get as close as possible to the point of the crash.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"