New iOS Crash

[mcw]

I have been testing my apps with the new iOS VM, things were looking good, very stable, until today.

All of a sudden I am crashing at startup a lot when I go to open my database. I have a bunch of crash logs that all show the same thing, the thread that loads the libsqlite3.dylib is the one that crashes.

This is new, I think something changed in the last 24-48 hours that is causing this. Any ideas?

This is from the crash log:

Incident Identifier: AE0458B9-E530-4BA5-ADFF-B28730307838
CrashReporter Key:   837fb8c6bdadd973fdf758431888393f7fa683ee
Hardware Model:      iPod5,1
Process:             VWMain [603]
Path:                /private/var/mobile/Containers/Bundle/Application/6A973AFC-16C9-4033-8DEF-80550089D5A1/VWMain.app/VWMain
Identifier:          com.readerware.xware.videoware
Version:             3.48 (3.48)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2015-08-24 16:09:29.530 -0700
Launch Time:         2015-08-24 16:06:53.255 -0700
OS Version:          iOS 8.4.1 (12H321)
Report Version:      104

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  13            


Thread 13 Crashed:
0   libsystem_kernel.dylib          0x3821cdf0 __pthread_kill + 8
1   libsystem_pthread.dylib         0x3829dc86 pthread_kill + 58
2   libsystem_c.dylib               0x381bb8bc abort + 72
3   libsystem_malloc.dylib          0x3824e396 szone_error + 330
4   libsystem_malloc.dylib          0x382466ee szone_free + 478
5   libsqlite3.dylib                0x37f2c0ae 0x37e95000 + 618670
6   libsqlite3.dylib                0x37ef40ec 0x37e95000 + 389356
7   libsqlite3.dylib                0x37eb02e0 sqlite3_finalize + 148
8   VWMain                          0x000d2c46 0x8b000 + 293958
9   VWMain                          0x000d1d1e 0x8b000 + 290078
10  VWMain                          0x000d1bf0 0x8b000 + 289776
11  VWMain                          0x000914a0 0x8b000 + 25760
12  VWMain                          0x007ca4e6 0x8b000 + 7599334
13  VWMain                          0x00732bb0 0x8b000 + 6978480
14  VWMain                          0x00733cb8 0x8b000 + 6982840
15  VWMain                          0x00734b62 0x8b000 + 6986594
16  VWMain                          0x007ca764 0x8b000 + 7599972
17  libsystem_pthread.dylib         0x3829cddc _pthread_body + 136
18  libsystem_pthread.dylib         0x3829cd4e _pthread_start + 114
19  libsystem_pthread.dylib         0x3829aaf8 thread_start + 4
                                  

[nick.m...@gmail.com]

Just to bump this, we have also have had at least 2 of our projects suddenly crashing since building in the last 48 hours.
The code hasn't been touched at our end but builds are now crashing.
These both use SQL as well.

[Shai Almog]

I'm unaware of any changes that went anywhere near these things but we did change the timer functionality on iOS to fix an issue recently. Are you using java.util.Timer?

[mcw]

Yes, I do use java.util.Timer

[mcw]

Does this look like a gc issue to you?

On Monday, August 24, 2015 at 9:49:19 PM UTC-7, Shai Almog wrote:

[Shai Almog]

It had me a bit stumped so I consulted with Steve since I don't use the SQLite API myself and he does use it in his apps.
He says that the thread sensitivity of the API is really great and this becomes a problem since the GC might finalize a connection that wasn't closed properly for you. If it does it on the GC thread then you might physically crash.

I don't like that one bit but I'm not sure how we can workaround it.

[Jérémy MARQUER]

Hi ! 

I'm facing a similar issue... 

How can we avoid GC when a connection or cursor is opened ? How can we improve database access to be threaded-safe ?

It's very difficult to avoid crash.

[Shai Almog]

Hi,
it's the wrong way to think about it...
The GC happens. You need to make sure to close connections and cursors when you are done with them. Notice that if you don't the simulator should print warnings to the console too.

[Jérémy MARQUER]

I'm pretty sure to close all my cursor in finally close using Util.cleanup(...) method. About the connection of database, It remain open during all life cycle.

I think my problem is related to thread. As you mentioned above, SQLite API is not thread safe. I will investigate to wrap this API to make it thread safe...

[Shai Almog]

It's crucial to only use one thread in your connections to SQLite. For simplicity we often use the EDT but that might be problematic. In that case you will need to guard that the EDT isn't accessing any SQLite data.

Notice that methods like invokeAndBlock() return different threads and not the same thread!

[Jérémy MARQUER]

Thanks. 

I've managed my implementation so all database access are executed into one thread. ThreadQueue implementation of Steve (https://gist.github.com/shannah/2becc8cf4e23b89ef78f) has helped me. FYI, I've override all methods of Database class ...