Crash in spatialite_cleanup_ex

[aa...@foreflight.com]

Hi,

I have built libspatialite 5.0.1 with proj 7.2.1. I am able to successfully initialize and use it in my iOS app. However, with this build I see a strange crash when I call spatialite_cleanup_ex. 

I have verified I am using spatialite_alloc_connection and spatialite_init_ex on the same thread that I call spatialite_cleanup_ex. This same code in my app has worked fine since 2014 using earlier versions of spatialite and proj.

When I dug into this it does appear the PROJ_handle on the spatialite cache is pointing to a bad memory address when I get to spatialite_cleanup_ex and that is why it fails.

The stack trace below is collected from a simple demo app I put together to see if I could replicate the crash outside of my primary project, and I was indeed able to. There is very little complexity in this demo app and only 1 thread (the main one). The backtrace matches exactly what I see in my app.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x23d04208)

    frame #0: 0x00000001009b7e8c FFMMapEngineIntegration`projCtx_t::~projCtx_t() + 20

    frame #1: 0x00000001009b8134 FFMMapEngineIntegration`pj_ctx_free + 16

    frame #2: 0x00000001009c41a4 FFMMapEngineIntegration`proj_context_destroy + 40

    frame #3: 0x00000001006d59c4 FFMMapEngineIntegration`free_internal_cache + 152

    frame #4: 0x000000010040fa5c FFMMapEngineIntegration`spatialite_cleanup_ex + 40

  * frame #5: 0x0000000100341f00 FFMMapEngineIntegration`-[MapObj dealloc](self=0x0000600002ef4640, _cmd="dealloc") at MapObj.m:39:9

[aa...@foreflight.com]

It appears the solution to our problem matches the solution proposed (and subsequently rejected) in this ticket:

https://www.gaia-gis.it/fossil/libspatialite/tktview/b26629729603daa8db4551a076bc4579422fd4b0?plaintext

If you are not using GEOS, then you enter a code path that allocates proj using the proj4 initializer instead of the new proj API. 

We are on iOS so this cannot be just a problem with emscripten. Rather it appears to be a bug with incorrect flag checks when not using GEOS.