[PROJ] Problems with sqlite3 and disk

[Javier Jimenez Shaw]

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 + 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260224/800347c8/attachment.htm>