BusyError: BusyError: database is locked

I’m getting this error during code intelligence loading:

BusyError: BusyError: database is locked

Komodo IDE, version 10.0.1, build 89237, platform linux-x86_64

Hi, while Komodo is closed, please go to your Komodo profile folder (~/.komodoide/10.0/) and navigate to the codeintel/ directory. Move the “symbols.db” file to “symbols.db.bak”. Then run Komodo again and see if that fixes anything.

It appears the “symbols.db” file is locked for whatever reason. Renaming it forces Komodo to create a new one that hopefully will not be locked. If all is good, you can remove the “.bak” version.

Well, it looks like this resolved the issue, thanks.
Anyway, the file was looking pretty normal before renaming, with correct permissions (644) and I was even able to open it with an sqlite viewer. The size was 185971712 bytes, maybe too big?

I’m not familiar enough with sqlite to know if that is possible or not, but it sounds reasonable. Let us know if it happens again. I’m glad it appears to be working :slight_smile:

Hi, I’ve been seeing the same issue. The editor keeps crashing when closing a tab. I can see the same error message.

I can’t find the profile folder.


I think you should do that:

This error would only occur when two processes are trying to write to the same database. Sqlite databases should never be locked for reading.

@mitchell does the db connection live in the main thread?

The separate codeintel process has write-access to the SQLite database. I don’t know how “go to symbol” in the main Komodo thread uses it, but I assume that’s read-access, so there shouldn’t be a lock.

Yeah that’s read-only.

We do have something that restarts the codeintel process when it crashes, perhaps the codeintel process crashed and as such the lock didnt get removed in a timely manner?

It’s not a crashing issue. I think codeintel might be scanning code faster than the symbol browser can insert it into its own database.

I can’t imagine that be the case, sqlite is a very mature database format. And we’re not doing anything creative with the way we are using it.

Well, all I know is BusyError comes from the database being busy writing stuff.

Looking at the source, it seems the DB connection is re-established and closed every time update_buf_data is called:


I’m guessing update_buf_data can be called in a thread. Most likely this is the issue.

We need to ensure the DB code lives entirely on the main thread, additionally it seems costly and error-prone to re-establish the db connection continually, this should only be done once and then kept alive for the duration of the process.

I’ll open a bug for this.