[PROJ] Problems with sqlite3 and disk

Javier Jimenez Shaw j1 at jimenezshaw.com
Tue Feb 24 08:27:27 PST 2026


Thank you Even. It was very helpful.
We will try to monitor those locations and their free space.
FYI, this was the what I wanted to diagnose with the PR
https://github.com/OSGeo/PROJ/pull/4553 ... and it worked! (the diagnostic
of the error message).

Cheers
Javier

On Tue, 24 Feb 2026 at 16:49, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
> we don't explicitly write temporary files, but sqlite3 can decide to do so
> (typically for a "heavy" request like listing all CRS with an order clause
> in it). https://sqlite.org/c3ref/temp_directory.html mentions "SQLite
> performs a search for an appropriate temporary file directory.".   Not very
> helpful. Source code at
> https://github.com/sqlite/sqlite/blob/da67225f04ad0470b54433fee31baf266e6630ef/src/os_unix.c#L6262
> shows it tries in that order (for Unix systems): SQLITE_TMPDIR env var,
> TMPDIR env var, /var/tmp, /usr/tmp, /tmp and "."
>
> For the embed proj.db, we have
> https://github.com/OSGeo/PROJ/blob/master/src/memvfs.c#L300  , which
> basically redirects to the above logic
>
> Even
> Le 24/02/2026 à 16:34, Javier Jimenez Shaw via PROJ a écrit :
>
> Hi
>
> We are having problems with sqlite3 and disk while running on iOS. It
> happens only from time to time. Restarting the application is usually
> enough.
>
> The first case returns an sqlite3 error 13: "database or disk is full"
> https://sqlite.org/rescode.html#full
> This is the message (trimmed)
>
> Fatal Exception: osgeo::proj::io::FactoryException
> SQLite error [ code = 13, msg = database or disk is full ] on SELECT * FROM (SELECT
> c.auth_name, c.code, c.name, c.type, c.deprecated, a.west_lon, a.south_lat, a.east_lon,
> a.north_lat, a.description, NULL, cb.name FROM geodetic_crs c LEFT JOIN usage u ON
> u.object_table_name = 'geodetic_crs'...
>
>
> And this is the stack trace
>
> 8  libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16
> 9  libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86
> 10 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90
> 11 proj 0x168434 osgeo::proj::io::SQLiteHandle::run(sqlite3_stmt*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::list<osgeo::proj::io::SQLValues, std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1468
> 12 proj 0x16a6e8 osgeo::proj::io::DatabaseContext::Private::run(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::list<osgeo::proj::io::SQLValues, std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1220
> 13 proj 0x1ad76c osgeo::proj::io::AuthorityFactory::getCRSInfoList() const + 2332
> ...
>
>
> There is another similar (but different) issue with error 10: "disk I/O
> error" https://sqlite.org/rescode.html#ioerr
>
> Fatal Exception: osgeo::proj::io::FactoryException
> SQLite error [ code = 10, msg = disk I/O error ] on SELECT name FROM "geodetic_datum" WHERE auth_name = ? AND code = ?
>
>
> Stack trace
>
> 9  libc++abi.dylib 0x11b80 std::terminate() + 108
>
> 10 proj 0x8270 __clang_call_terminate + 1411 proj 0xad1e8 osgeo::proj::common::IdentifiedObject::_isEquivalentTo(osgeo::proj::common::IdentifiedObject const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 234
> 12 proj 0xe82f4 osgeo::proj::datum::Datum::_isEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 100
> 13 proj 0xed7ac osgeo::proj::datum::GeodeticReferenceFrame::isEquivalentToNoExactTypeCheck(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 96
> 14 proj 0xc0774 osgeo::proj::crs::SingleCRS::baseIsEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 456
> 15 proj 0xc8eb0 osgeo::proj::crs::GeographicCRS::_isEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 172
> 16 proj 0xc627c osgeo::proj::crs::GeodeticCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 724
> 17 proj 0xd072c osgeo::proj::crs::ProjectedCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 1184
> 18 proj 0xd4028 osgeo::proj::crs::ProjectedCRS::_identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 44
> ...
>
>
> Are we writing anything to disk at runtime related to sqlite3? Even a
> temporary file? Where?
> If yes, would this problem be fixed if we embed proj.db in the library?
> Currently we are using it as an external file.
>
> My only guess would be that sqlite3 is creating a temporary file in a
> folder with very little space (like /tmp), because the phone should have a
> lot of free space for normal storage.
>
> Thank you
> Javier.
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260224/ba26e819/attachment.htm>


More information about the PROJ mailing list