Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Attach encrypted database results in Out of Memory Error #1799

Closed
mtissington opened this issue Mar 12, 2019 · 18 comments
Closed

Attach encrypted database results in Out of Memory Error #1799

mtissington opened this issue Mar 12, 2019 · 18 comments
Labels
bug Confirmed bugs or reports that are very likely to be bugs. release blocker Bugs that are serious enough to block our next release

Comments

@mtissington
Copy link

mtissington commented Mar 12, 2019 •
edited
Loading

Using the latest nightly build on Windows 10 (also happening with the release build!)

I have two encrypted databases (same key).

I open the first database, then attach the second database.

If I try to execute any SQL that includes any tables in the attached database I'm getting an Out Of Memory Error.

If I try to browse any of the attached tables - at the bottom of the screen where row count should appear it says "determining count of rows..."

If I try the following "PRAGMA integrity_check;" I get an Out Of Memory Error.

If I execute "DETACH DATABASE database_name" then everything returns to normal.
@chrisjlocke
Copy link
Member

...and I assume opening the second database and performing an integrity check also comes back clean?
...and I assume running any SQL statements on the second database (alone) works fine?
Out of interest, what happens if you open the second database and attach the first database (if that makes sense...) and perform actions on the now attached database.

@mtissington
Copy link
Author

Integrity check on stand alone second database is clean and SQL statements work fine.
Same error if I swap the databases (open second, attach first).

@justinclift
Copy link
Member

Ouch. Probably better to not generate the 3.11.2 builds today after all. This sounds like a bug of some sort that's likely present in both our release and master branches. 😉

@justinclift justinclift added the bug Confirmed bugs or reports that are very likely to be bugs. label Mar 13, 2019
@mtissington
Copy link
Author

mtissington commented Mar 22, 2019 •
edited
Loading

The latest build now allows me to Attach a database however
However executing any sql statement still result in Out Of Memory error.

Am also now getting a new error when trying to detach the database using detach database name ..

The error is (database name is import)

Execution finished with errors.
Result: database import is locked
At line 1:
DETACH DATABASE import;

@chrisjlocke
Copy link
Member

Is that after running successful SQL statements?
Are the statements wrapped in a transaction? (wondering if some transaction is keeping it open?)

@mtissington
Copy link
Author

mtissington commented Mar 22, 2019 •
edited
Loading

Hmm, there is something really messed up around Attach and the issuing 'detach database name'
Now I'm no longer able to get the error database is locked when trying to detach.

UPDATE: - The folllowing only SOMETIMES works.

However if I do the following

  1. Click attach button and attach encrypted database (not tried plain db) as 'test'
  2. Execute sql 'select * from test.sqlite_master'
  3. This works and I can then select other tables without getting the original Out of Memory error.

If I don't do (2) first then any other sql seems to generate the Out Of Memory error...

Very strange.

@mtissington
Copy link
Author

This is really critical for us - needing to Attach and execute sql statements.

Is there a version that does NOT cause the Out of Memory error?

Thanks.

@mtissington
Copy link
Author

This seems to be related to the database being encrypted.

If I decrypted both databases and then tried the above (same version of DB Browser) everything works correctly.

Hope this helps...

@chrisjlocke chrisjlocke mentioned this issue Mar 23, 2019
Closed
@chrisjlocke
Copy link
Member

(See also #1814)

@justinclift
Copy link
Member

@MKleusberg This sounds like it's related to #1758. Maybe the fix for that needs a bit of adjusting? 😉

Note - Am now going through the outstanding GitHub Notifications I've been mostly ignoring for the past 2 weeks, prior to building the 3.11.2 release binaries. I have a feeling this issue might be a release blocker. 😦

@justinclift justinclift added the release blocker Bugs that are serious enough to block our next release label Mar 23, 2019
@justinclift justinclift mentioned this issue Mar 23, 2019
Closed
13 tasks
MKleusberg added a commit that referenced this issue Mar 25, 2019
@MKleusberg
Use cipher_default_* PRAGMAs when attaching an encrypted database
564d54e 
When attaching an SQLCipher encrypted database we need to set the page
size, KDF iterations, and HMAC and KDF algorithms. This needs to be done
before actually attaching the database but we tried to do it afterwards
which silently fails until the first statement is executed on the
attached database. This commit modifies the "default" values for these
pragmas in order to make sure SQLCipher uses the correct values right at
the beginning.

See issue #1799.
@MKleusberg
Copy link
Member

This should be fixed too in @justinclift's build 😄 Can you try this as well, @mtissington?

@mtissington
Copy link
Author

@MKleusberg waiting in anticipation ... 😄

@mtissington
Copy link
Author

Still getting both errors ...

@justinclift
Copy link
Member

@mtissington This is fixed now isn't it?

MKleusberg added a commit that referenced this issue Mar 30, 2019
@MKleusberg
Use cipher_default_* PRAGMAs when attaching an encrypted database
b8faa05 
When attaching an SQLCipher encrypted database we need to set the page
size, KDF iterations, and HMAC and KDF algorithms. This needs to be done
before actually attaching the database but we tried to do it afterwards
which silently fails until the first statement is executed on the
attached database. This commit modifies the "default" values for these
pragmas in order to make sure SQLCipher uses the correct values right at
the beginning.

See issue #1799.
@mtissington
Copy link
Author

mtissington commented Mar 30, 2019 via email •
edited by justinclift
Loading

@justinclift
Copy link
Member

Thanks @mtissington 😄

Looks like all we're waiting for now, is updated translations for strings. Then we can do the 3.11.2 release. 😄

@chrisjlocke
Copy link
Member

Purposely broke the (spam?) link. Looks like spam but wasn't sure whether to delete or not. Thinking 'yeah' but also 'meh'. Seemed to go to a legit page, but couldn't see the point of it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Confirmed bugs or reports that are very likely to be bugs. release blocker Bugs that are serious enough to block our next release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@justinclift @MKleusberg @mtissington @chrisjlocke and others