Objectmapper: Memory leaks and eventual crashing

[phaddius]

I've been battling this random heap corruption crash over the past few months, I can only catch it when Crashlytics reports it in my production app. It's always a EXC_BAD_ACCESS KERN_INVALID_ADDRESS, and generally the stack is different for each crash, except that the root (bottom) of the stack always points to Entry.swift (Entry is one of my ObjectMapper models), in the exact same line number, which is not a real line of code, but a variable declaration.

Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x190725704 objc_object::release() + 8
1 CoreFoundation 0x191bb1fe4 -[__NSArrayI dealloc] + 84
2 libobjc.A.dylib 0x190725fe0 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 704
3 CoreFoundation 0x191bae028 _CFAutoreleasePoolPop + 28
4 CoreFoundation 0x191bb1f48 CFRunLoopTimerInvalidate + 640
5 CoreFoundation 0x191c82f20 __CFRunLoopDoTimer + 924
6 CoreFoundation 0x191c827a8 __CFRunLoopDoTimers + 244
7 CoreFoundation 0x191c803a4 __CFRunLoopRun + 1572
8 CoreFoundation 0x191bae2b8 CFRunLoopRunSpecific + 444
9 GraphicsServices 0x193662198 GSEventRunModal + 180
10 UIKit 0x197bf57fc -[UIApplication _run] + 684
11 UIKit 0x197bf0534 UIApplicationMain + 208
12 \ 13 libdispatch.dylib 0x190b915b8 (Missing)

When I run the Leaks Instrument, I see a lot of memory leaks that involve ObjectMapper, and I've attached some screenshots of what the stack traces look like:

I'm 95% positive I'm using things properly, but of course I could always be wrong. I'd love to get someone else's eyeballs on this. My app has sensitive information on it, so I don't want to paste any code or my api data here, but I'd be glad to email it to whoever is investigating this.

[pschneider]

I've seen similar things with an object mapper model of ours, with not reproducible crash reports as the line is no actual code. Will post something if it happens again.

[mrobert]

I am also seeing similar memory leaks, specifically where I'm mapping an optional array of custom objects, much like in the README example:

class User: Mappable {
    var friends: [User]?    // Array of Users

    required init?(map: Map) {

    }

    // Mappable
    func mapping(map: Map) {
        friends     <- map["friends"]
    }
}

My 'User' object is also Mappable. The mappings have been working, just not sure how long they have been leaking memory.

[rajanbalana]

Any update for this? I am also seeing similar memory leak.

[rpatoni]

Is there any update on this issue?

[AntonTheDev]

Is this still being looked at? I'm getting the same error of and on, can't reproduce it, but it definitely has something to do with an array of custom objects

[ThuggishNuggets]

Definitely still an issue in 2.2.9. I'm seeing this when mapping custom objects with an optional array property containing more custom objects using Mappable protocol conformance.

Trying to track down a workaround.

[phoney]

A few comments.

The stack trace shows an over-released object being released from an autorelease pool and causing a crash. The stack in main isn't useful. All it tells you is that this is on thread-1. All code in thread-1 starts from the entry point of your app. You can see it in all the stack traces that are above and you can always see it in the debugger when you hit a breakpoint.

This is likely to be a compiler bug. Tracking it down would probably be helped by running a Release build with Zombies turned on. The over-released objects will become Zombie and the debugger will stop when a zombie is messaged.

I reported a compiler bug like this about a year ago and it was fixed early in 2017. The over-release was caused by having whole-module-optimization turned on.

[ThuggishNuggets]

Tried enabling Zombies, but none are ever messaged for us even with optimizations enabled.

[ThuggishNuggets]

The leaks disappear when optimizations are disabled so it may just be a compiler bug.

[phaddius]

A couple of notes. I've converted my objects to ImmutableMappable and have noticed the crashes diminishing. I've also noticed the crashes NOT happening in iOS 11, so maybe they've fixed the underlying issue.

[choioi]

Change model from class to struct will be fixed this leak .