Crash "freeing unallocated pointer" in FMDatabase.m line 1073

[georgbachmann]

My app wasn't yet recompiled for iOS10, but since iOS10 got released, I have a lot of those crashes:

Crashed: fmdb.<FMDatabaseQueue: 0x176653c50>
SIGABRT ABORT 0x0000000188292014

in FMDatabase.m line 1073I am using Version 2.6.2

The main problem is that I can't reproduce the crash... Also the stacktrace isn't very helpful to me...

FMDatabase.m line 1073
-[FMDatabase executeUpdate:error:withArgumentsInArray:orDictionary:orVAList:]

FMDatabase.m line 1239
-[FMDatabase executeUpdate:withErrorAndBindings:]

BFTourInfoDatabase.m line 377
__45-[BFTourInfoDatabase updateTours:completion:]_block_invoke_2

FMDatabaseQueue.m line 192
__46-[FMDatabaseQueue beginTransaction:withBlock:]_block_invoke

_dispatch_client_callout + 16

_dispatch_barrier_sync_f_invoke + 84

FMDatabaseQueue.m line 203
-[FMDatabaseQueue beginTransaction:withBlock:]

Does anybody else have this crash? Any help is very appreciated as I'd like to update my app soon to fix this problem!

[roblav96]

@georgbachmann Same here. Have you found a solution?

[ccgus]

Please show the full backtrace, and code snippets that are calling FMDB would be helpful as well.

[georgbachmann]

I don't have more than the snipped above. I also can't reproduce it myself. I only have crashlogs and they all look the same. But it's affecting quite a lot of my users!!! @roblav96 do you maybe have some better crashlogs? Or did you manage to reproduce it?

[ccgus]

You don't have the source to the app anymore?

[georgbachmann]

Ah... I meant stack trace... give me a sec... I'll post my code in a second

[roblav96]

Here's the snippet I'm using:

FMDatabase *db = [FMDatabase databaseWithPath:@"/tmp/tmp.db"];
if (![db open]) {
    NSLog(@"!db open AWW BOO...")
    [db dealloc];
    return;
}

It logs AWW BOO... throws fmdb error opening!: 14 then crashes.

Let me go find the crash log,

[georgbachmann]

My code is basically this:

dispatch_async(self.backgroundQueue, ^{

    FMDatabaseQueue *queue = [FMDatabaseQueue databaseQueueWithPath:self.    databasePath];

    [queue inTransaction:^(FMDatabase *db, BOOL *rollback) {

      BOOL success = [db executeUpdate:@"INSERT OR REPLACE INTO tours (id, ..    .) VALUES (?, ...)" withErrorAndBindings:&error, xxx];

      *rollback = NO;

    });
}];

And the executeUpdate is the line it crashes

[roblav96]

I'm on ios10, xcode8, and iPhone 5.

pod 'FMDB'

[georgbachmann]

Jup, for me it also only happens on iOS10

[robertmryan]

@roblav96 - Error 14 is SQLITE_CANTOPEN. If you want to open temporary file, use NSTemporaryDirectory and append your filename to that. iOS applications are sandboxed and you want to use your app's temp folder, not a hard coded folder.

---

For example:

NSString *path = [NSTemporaryDirectory() stringByAppendingPathComponent:@"tmp.db"];
FMDatabase *db = [FMDatabase databaseWithPath:path];

[ccgus]

@georgbachmann There's not enough in your code to be able to guess what might be going on, sorry. A full backtrace, and the actual code you're using might help.

[roblav96]

@robertmryan That did it :D

I'm a n00b at this. I've been doing web development for 6 years and just started experimenting with native programming.

Thank you!!!

[georgbachmann]

Here's a full stacktrace from Fabric

[robertmryan]

@roblav96 - No problem.

By the way, you should never call dealloc. (Well, there's a single exception to that rule, that in non-ARC code, you call [super dealloc] in your own dealloc implementation. But with that one exception, you never call dealloc yourself.) The system calls that when the object is released.

In ARC code, remove your strong references (e.g. if it's a property, set that property to nil) and it will be deallocated for you if and when there are no more strong references.

[ccgus]

@georgbachmann that's a partial backtrace of a single thread. Can you show them all? Preferably linking to a text file with them all? It's hard to copy and search for them when given images.

[georgbachmann]

@ccgus and as far as the code goes... basically it's just the code above. there is a for loop around the executeUpdate:withErrorAndBindings: and there are some more values than the id that are filled. They are NSNumbers and NSStrings.

It's shitty that I don't have more on that... It's just that since iOS10 I start getting a lot of crashed here...

[georgbachmann]

Here's a full stacktrace: http://pastebin.com/fX76Xuh2

[ccgus]

@georgbachmann Thanks for that. Nothing jumps out at first glance, though that there's a free_tiny as well as nano_free going on at the same time in two different threads does make you wonder… do your other stack traces show both frees happing at the same time?

I would make sure that the values you're using for the update aren't spontaneously going away (like being deallocated on the main thread). I would also make sure that the database isn't being closed on another thread somehow. It's generally safe to use the queue on multiple threads- but it's maybe possible to close things.

[roblav96]

@robertmryan So in this snippet,

if (![db open]) {
    [db release];
    return;
}

I think the method release is called off NSObject but I couldn't find it but I did find dealloc. That was my thought process. lol I gotta research more on how memory is managed.

Thanks for the tip mate!!!

[robertmryan]

@roblav96 - Sorry for the confusion. The [db release] is an anachronism, required in manual referencing code. But now that almost all of us are using Automatic Reference Counting, it's simply not needed. If you do anything, setting the db to nil (or, if it's a local variable, just let it fall out of scope) is sufficient:

if (![db open]) {
    db = nil;
    return;
}

[roblav96]

@robertmryan Thanks for the pointers! There's sooo much to learn. haha

[georgbachmann]

@ccgus just had a look at a few more crashlogs... they don't have nano and tiny frees

My database never get's closed by me... I get a reference to the queue like so: FMDatabaseQueue *queue = [FMDatabaseQueue databaseQueueWithPath:self.databasePath]; and then only use inTransaction: for updating and inDatabase: for searching. So no manual opens or closes of the database (I close my FMResultSet though after executeQuery:withArgumentsInArray:... is that fine?)

Also the values I pass into the update are extracted from an NSDictionary right before the update and passed in. So there is a reference to them and therefore they shouldn't be released by anybody...

Also I only use one single background queue for reading and writing... So concurrency shouldn't be a problem there...

[ccgus]

Sounds like things are fine then. I'm stumped.

[Amitmundra]

I am also facing lot of crashes in FMDB class, I am not using FMDatabaseQueue, It was not crashing in previous version of iOS, Suddenly getting lot of crashes in iOS10.

PLEASE HELP TO RESOLVE ISSUE ASAP, PLEASE FIND LOG

MY ERROR LOG #10. Crashed: com.apple.root.default-qos 0 libsqlite3.dylib 0x18dea01b4 (null) + 872 1 libsqlite3.dylib 0x18dea0188 (null) + 828 2 libsqlite3.dylib 0x18df023c8 (null) + 3308 3 libsqlite3.dylib 0x18df1e324 (null) + 64052 4 libsqlite3.dylib 0x18dec88b0 (null) + 4316 5 libsqlite3.dylib 0x18deb8424 (null) + 7064 6 libsqlite3.dylib 0x18deb6ae4 sqlite3_step + 600 7 connecta6 0x1001d5730 -FMResultSet next

13 libdispatch.dylib 0x18c819200 _dispatch_call_block_and_release + 24 14 libdispatch.dylib 0x18c8191c0 _dispatch_client_callout + 16 15 libdispatch.dylib 0x18c827ab4 _dispatch_queue_override_invoke + 732 16 libdispatch.dylib 0x18c82938c _dispatch_root_queue_drain + 572 17 libdispatch.dylib 0x18c8290ec _dispatch_worker_thread3 + 124 18 libsystem_pthread.dylib 0x18ca212c8 _pthread_wqthread + 1288 19 libsystem_pthread.dylib 0x18ca20db4 start_wqthread + 4

[georgbachmann]

@ccgus I found one more different crash: http://pastebin.com/YTEvncMi This time it's a DB-close... also just happening on iOS 10 Might be the same as @Amitmundra has... At least after a FMResultSet next there might me a DB-Close... Do you have apps out there using your Framework? Don't you see iOS 10 crashes?

[georgbachmann]

Alright.... one more different iOS10 Crashlog: http://pastebin.com/8swk7pg7 Hopefully one of them will shed light on what's going on here :)

[ccgus]

@georgbachmann I don't ship any iOS apps. I haven't heard from anyone else, besides those in this thread, about these crashes.

[Wolar]

@ccgus Hey, did you or anyone else manage to find whats the problem, how to solve it or how to reproduce it? Since the iOS10 we are having the same problems as described above (hundreds of users experiencing these kinds of crashes and we are unable to reproduce the issue).

Attaching some crash logs (we have quite a lot of them)

2016-11-22_16-37-18.6350_-0800-4f864ea5c1bbe73b1228ce0b0c330bd6320398d4.txt

2016-11-22_16-42-53.8877_-0500-34806c94fc8de740bdd3bcddd64a15e4758423f4.txt

2016-11-22_17-59-23.9039_-0800-4cbe9c6b827a2c6e643509a1a27308ab6112a854.txt

There are several other crashes on other places that seems to be related (also iOS10 only) but there is not that many like the one above

2016-11-20_13-53-59.1439_-0500-ff304c5beb06579d2dfb02e6d43e95d67e069ed1.txt

[ccgus]

I've not been able to find the problem, or reproduce it. A reproducible case would go a long way.

[Wolar]

I think it's the same problem like these guys https://github.com/Adobe-Marketing-Cloud/mobile-services/issues/187 have faced. We are also storing the analytics data from application and extensions to the database in shared container and accessing it from background.

Like the reporter said there "It seems like this happens when the app is in background and SDK tries to access its database when it's located in a shared container"

I will try to reproduce it in some example as soon as I have some free time to do so. Hope it helps a little.