Crash in FMResultSet nextWithError

[emuye]

We see occasional crashes calling FMResultSet nextWithError. These crashes are generally coming in through Fabric so we don't have steps to reproduce the issue. I've included a sample backtrace. Any idea what could be causing the crash?

This is using the latest FMDB (2.7.4)

crash.txt

[ccgus]

Looks like a rekey is going on with an encrypted db. Do the crashes always occur with a rekey?

[emuye]

I'm not sure if they always occur with a rekey but I went through a bunch of the backtraces and many were with a rekey. Here's another trace which has a rekey but looks slightly different:

crash_2.txt

[ccgus]

It's been a while since I've used sqlite's encryption extensions, but I'm pretty sure you want to make sure that nothing else is going on any other threads when a rekey is happening.

I see in two other threads of this latest stack trace that there's a wait on inDatabase:, which I think in theory should be OK… but it still makes me wonder if that's what is causing the problem.

And I also notice that sqlite3_rekey isn't being handled called directly by FMDB- which I don't think I've encountered before. What encryption extension are you using? Or are you not using an encryption extension at all?

[emuye]

We're not using any encryption extensions.

In the first trace I believe only the thread that crashed is actively in inDatabase:

[ccgus]

Do you know what the query it's calling is?

[emuye]

No only the backtrace is available as we're seeing these crashes come in through Fabric. While the crash happens frequently we haven't been able to reproduce on demand.

[ccgus]

rekey is, as far as I'm aware, only used for the encryption extensions. I'm not sure why it would then be showing up in the stack trace.

Wish I had a better answer for you, sorry.

[yeahphil]

Hiya,

I'm seeing something similar, from a pretty similar looking trace that's crashing within libsqlite3 called from -nextWithError:, and another one originating from a call to -executeUpdate:

This is also in an app not using encryption, and I also don't have a repro 🙁.

I'm starting to dig in, my working hypotheses:

• This is gonna turn out to be some sort of thread safety mistake, prob me misusing FMDatabaseQueue
• The presence of sqlite3_rekey is incidental and some internal libsqlite3 detail that's not actually doing anything. I tried taking a look at the libsqlite3 source to confirm that and it's, uh, not exactly straightforward to see when rekey would get called internally.

Would love to hear if those sound reasonable, and what the resolution is if you solve your issue, @emuye.

[ccgus]

It's kind of hard to misuse FMDatabaseQueue, as long as you're not holding onto the database handle outside of the blocks… but I guess it's possible.

Another idea- I wonder if this is a problem of the file system locking when the app goes to the background? I don't do any iOS dev, but I believe that's something you have to look out for…

[emuye]

The file system locking is an interesting idea. It's possible although I'm pretty sure we've seen this with the app just running (not being backgrounded).

[yeahphil]

I agree, that's interesting but in the crashes I'm seeing looks like the app is foregrounded & not transitioning.

Still digging on my end, and will update when I know more...

[myusuf3]

@yeahphil any updates we are also running into this now, similarly we aren't using encryption nor can we reproduce on demand.

[myusuf3]

@emuye anything on your end?

[yeahphil]

@myusuf3 haven't cracked this one yet. I continue to guess it's something I'm doing wrong: somehow passing a db handle in a way that results in it getting used on a concurrent queue or similar. But it's not obvious how that would be happening, and make changes/ship/observe has got to be one of the harder ways to debug 😬

[emuye]

@myusuf3 I continue to see the crash through in Fabric but still don't have any insights as to what's happening.