[PROJ] Problems with sqlite3 and disk

[Even Rouault]

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 <http://c.name>, c.type, c.deprecated, a.west_lon, a.south_lat, a.east_lon,
> a.north_lat, a.description, NULL,cb.name <http://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 0x11bdcstd::__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 0x168434osgeo::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 0x16a6e8osgeo::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 0x1ad76cosgeo::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 + 14
> 11 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 list
> PROJ at lists.osgeo.org
> https://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/bdda8954/attachment-0001.htm>