Debugging SEGV_ACCERR with invalid pointer

I have a SIGSEGV/SEGV_ACCERR crash like this:

Thread 0 Crashed:
0   libobjc.A.dylib     0x39c69f2a _objc_release + 10
1   CoreFoundation      0x31cf4441 __CFAutoreleasePoolPop + 17
2   Foundation          0x326c8185 __NSThreadPerformPerform + 605
3   CoreFoundation      0x31d86683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
4   CoreFoundation      0x31d85ee9 __CFRunLoopDoSources0 + 213
5   CoreFoundation      0x31d84cb7 __CFRunLoopRun + 647
6   CoreFoundation      0x31cf7ebd _CFRunLoopRunSpecific + 357
7   CoreFoundation      0x31cf7d49 _CFRunLoopRunInMode + 105
8   GraphicsServices    0x358c32eb _GSEventRunModal + 75
9   UIKit               0x33c0d301 _UIApplicationMain + 1121
10  MyApp               0x0007471b main (main.m:15)

The problem is that the SEGV_ACCERR address is always invalid. I have seen the following addresses: 0xa2142302, 0x51e9d281, 0x11e1af4e, 0x10, for example. My understanding is that the SEGV_ACCERR address inside _objc_release() should be the pointer either to the object being released or to its class object. As you see, the first three of the example addresses above are misaligned (given that malloc() returns only 16-byte aligned addresses) and the last one is obviously bogus.

The crash happens in __CFAutoreleasePoolPop(), which indicates that the bogus pointers somehow got collected by an autorelease pool. My understanding is that the only way for a pointer to get collected by an autorelease pool is to be a valid Obj-C object which received -autorelease message.

If both of my premises are correct, I'm having a bad case of memory corruption. In other words, a valid Obj-C object received -autorelease, got into an autorelease pool, its memory location was overwritten with garbage and when the autorelease pool tried to release it, it dereferenced an invalid pointer.

What sorts of bugs can corrupt memory like this? I can think of memcpy()-like functions, stack overflows, buffer overflows. What else can I look for?

Below is a typical example of the thread state. SEGV_ACCERR address is always r1 + 16, r10 is always 0xa3a3a3a3 and r6 = r4 + 48, but that's all I can say.

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0x51e9d281
...
Thread 0 crashed with ARM Thread State:
  r0: 0x1e865730     r1: 0x51e9d271     r2: 0x00000002     r3: 0xc4d443fb 
  r4: 0x1e0ff000     r5: 0x3bc64bd0     r6: 0x1e0ff030     r7: 0x2fdbdddc 
  r8: 0x1e0ff030     r9: 0x0015991c    r10: 0xa3a3a3a3    r11: 0x00000088 
  ip: 0x3bc5f800     sp: 0x2fdbddbc     lr: 0x39c69489     pc: 0x39c69f2a 
cpsr: 0x20000030 

Unfortunately, I cannot reproduce the crash myself, all the reports are from actual users. Any ideas are greatly appreciated.