|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #74883 SQLite3::__construct() produces "out of memory" exception with invalid flags
Submitted: 2017-07-08 21:00 UTC Modified: 2017-07-17 13:55 UTC
From: jeroen at treurniet dot us Assigned: danack (profile)
Status: Closed Package: SQLite related
PHP Version: 7.1.7 OS: Windows
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: jeroen at treurniet dot us
New email:
PHP Version: OS:


 [2017-07-08 21:00 UTC] jeroen at treurniet dot us
When opening a SQLite3 database with both the SQLITE3_OPEN_READONLY and SQLITE3_OPEN_CREATE flags, an exception thrown which reads "Unable to open database: out of memory".

While it is understandable that it doesn't make sense to combine the two flags (since creating a new database would require writing, and opening an empty database that cannot be written to is probably not very helpful), the "out of memory" error is confusing, and does not seem like an accurate description of the problem. Especially since the documentation for neither SQLite3::__construct() and SQLite3::open() hints to this, I was personally stuck for some time figuring out why it was telling me it was out of memory.

This behavior occurs regardless of whether or not the specified database file actually exists/is readable.

I propose that when either of these functions is called with SQLITE3_OPEN_READONLY, they should either silently ignore the SQLITE3_OPEN_CREATE flag if it is specified, or produce an E_NOTICE with a more helpful message, rather than throwing a fatal error with an unhelpful description ("out of memory").

Test script:
$db = new SQLite3( "my_database.db", SQLITE3_OPEN_READONLY | SQLITE3_OPEN_CREATE );

Expected result:
Either silently ignore the SQLITE3_OPEN_CREATE flag, or throw an E_NOTICE rather than an exception.

Actual result:
Fatal error: Uncaught Exception: Unable to open database: out of memory in ...


ignore-open-create-with-open-readonly (last revision 2017-07-08 21:42 UTC by jeroen at treurniet dot us)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-08 21:57 UTC]
Thanks for the report. As for me, the suggested solution doesn't sound optimal. It is application dependent, so why should be one flag removed in favor of another one? Another script might need it in exactly opposite way. IMO it is merely about improving the error check, not more. SQLite should be able to detect such cases.

 [2017-07-08 23:38 UTC]
Automatic comment on behalf of ab
Log: Fixed bug #74883 SQLite3::__construct() produces "out of memory" exception with invalid flags
 [2017-07-08 23:38 UTC]
-Status: Open +Status: Closed
 [2017-07-09 16:32 UTC]
The error message originate in the underlying SQLite library. I've sent a bug report to the SQLite mailing list, to see if the message can be improved.

> they should either silently ignore

No. Programs shouldn't silently discard data.

> rather than throwing a fatal error with an unhelpful description ("out of memory").

It doesn't throw an 'error'; it throws an Exception, and your code code should be catching exceptions both at the location where you're calling new SQLite3() - to catch expected error conditions, such as the database file not being open-able, and also at the top level of the application, to log all 'unexpected' exceptions that you weren't aware that could occur..

> produce an E_NOTICE with a more helpful message

No. The error message should be better, but E_NOTICES are not a good way to handle failed constructors. All constructors must either succeed or throw an exception. This was decided by RFC recently:
 [2017-07-17 13:55 UTC]
-Assigned To: +Assigned To: danack
 [2017-07-17 13:55 UTC]
After some investigation, this problem does like in the underlying SQLite library, that isn't present when compiled with an up-to-date version.

I'll open a separate issue to update SQLite.
 [2017-08-05 14:23 UTC] 170805 at 0x440x48 dot com
The fix applied in this thread makes PHP7.1.8 use sqlite3_errstr. This symbol is not available in sqlite version 3.6.20, which is system default on RHEL6.

Remi's repo has a patch for this his the latest SRPM:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jun 17 19:01:30 2024 UTC