On iOS, are 0x0000000000000026, 0x000000000000001c, 0x000000000000005a examples of tagged pointers?

On iOS, are 0x0000000000000026, 0x000000000000001c, 0x000000000000005a examples of tagged pointers?



On iOS 11, when I intentionally create objects which would turn out to be tagged pointers, they start with 0xB, instead of the 0x0000000000000026, 0x000000000000001c, 0x000000000000005a values that are showing up in my crash reports as invalid addresses. I think these are likely tagged pointers, but they aren't formatted like tagged pointers that I see in the debugger.



What about 0x0000000000000010, 0x0000000000000020, 0x0000000000000030 ? They all have a trailing 0, but they sure look suspiciously small to be real pointers.






You probably want to give a bit more context, with a bit of code, examples of where you see that (including logs and/or screenshots)... From what I understand, tagged pointers have 1 as their least significant bit (i.e., they're odd).

– jcaron
Sep 10 '18 at 22:08




1 Answer
1



The implementation details of tagged pointers changes from release to release and architecture to architecture. With that said, those really don't look like tagged pointers.



What is most likely is that some piece of code is dereferencing into a struct or object that is unexpectedly NULL or nil.



Run this code:


struct bob
void *a;
void *b;
void *c;
char d[42];
;

int main(int argc, const char * argv)
struct bob *fred = NULL;

fred->d[2] = 'q';
return 0;



You'll get this crash (on x86_64): Thread 1: EXC_BAD_ACCESS (code=1, address=0x1a)


Thread 1: EXC_BAD_ACCESS (code=1, address=0x1a)



That is, it is trying to dereference through 0x0. So, more likely than not, you have a struct/object reference that is NULL and your code is trying to dereference an element or instance variable that is offset by the hex #s you listed from the beginning.






Thanks. So, if I understand you correctly, when I get a EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000030 in crashlytics with a stack trace like 0 libobjc.A.dylib 0x1838697f4 objc_object::release() + 16 1 Security 0x18531b6b4 SecCertificateDestroy + 208 2 CoreFoundation 0x18463cc3c _CFRelease + 216 3 CoreFoundation 0x1845611b4 -[__NSArrayM dealloc] + 140 it has something to do with possibly a null pointer somewhere in the security certificate?

– Ben Spratling
Sep 12 '18 at 21:25



EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000030


0 libobjc.A.dylib 0x1838697f4 objc_object::release() + 16 1 Security 0x18531b6b4 SecCertificateDestroy + 208 2 CoreFoundation 0x18463cc3c _CFRelease + 216 3 CoreFoundation 0x1845611b4 -[__NSArrayM dealloc] + 140






That would be a reasonable analysis, yes.

– bbum
Sep 13 '18 at 3:02



Thanks for contributing an answer to Stack Overflow!



But avoid



To learn more, see our tips on writing great answers.



Required, but never shown



Required, but never shown




By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Edmonton

Crossroads (UK TV series)