Address Sanitizer and Objective-C garbage collection (GC) incompatible?

Hi all,

Has anyone tried asan with Obj-C GC?

They seem incompatible. :frowning: Even with a trivial example that just calls NSApplicationLoad() in main().

The OS spews a bunch of these:

a.out(8598,0x7fff7789c960) malloc: reference count underflow for 0x400410660, break on auto_refcount_underflow_error to debug.
2012-12-13 13:02:34.723 a.out[8598:707] storing a non-GC object 0x109733e48 in a GC collection, break on CFCollection_non_gc_storage_error to debug.

then asan spews:

==8598== ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x00010aab4000

I can file a bug with details, but thought I'd check here in case I'm not the first to try....

Thanks,

Hi Sean,

Are you aware that ObjC GC is deprecated in Mountain Lion?

-Chris

Very much so. But until I convert to ARC, I'd still like to benefit from asan, if I can.

(Aside: Xcode is still a GC app too. As you know, it's non-trivial to just change the entire memory management of a large codebase overnight.)

Cheers,

Yep, I'm aware of that, I just wanted to make sure you were on the right path. Just MHO, but I wouldn't expect much traction on improving tools for ObjC GC going forward.

-Chris

Hi Sean,

Hi all,

Has anyone tried asan with Obj-C GC?

They seem incompatible. :frowning: Even with a trivial example that just calls NSApplicationLoad() in main().

This is very likely.

The OS spews a bunch of these:

a.out(8598,0x7fff7789c960) malloc: reference count underflow for 0x400410660, break on auto_refcount_underflow_error to debug.
2012-12-13 13:02:34.723 a.out[8598:707] storing a non-GC object 0x109733e48 in a GC collection, break on CFCollection_non_gc_storage_error to debug.

then asan spews:

==8598== ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x00010aab4000

This happens if an address allocated by some part of ObjC run-time is passed to the regular C free (or C++ delete).
It may be possible to fix this by intercepting the relevant part of ObjC run-time in asan library.
I suggest to wait until asan transitions from mach_override to “function interposition” (soon!) and then give it a try.
Since none of us (asan team) is an ObjC expert and ObjC GC is deprecated we are unlikely to handle the problem ourselves.

–kcc

Well, I created a bug incase it's expectedly easy to fix, like bug #13794 was:

<http://llvm.org/bugs/show_bug.cgi?id=14674>

Cheers,

Sean

I’ve updated that bug. I hope that the new dynamic runtime will eliminate the problems with GC.
Basically with the new runtime all the allocations from the GC zone will be instead done using the ASan allocator. But this will lead to increased memory consumption, because none of those allocations will be garbage collected.