1849842 - IndexedDB UnknownErr: ActorsParent.cpp:5432

Status: RESOLVED FIXED

(Core :: Storage: IndexedDB, defect, P3)

Description

[juraj.masiar]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

I'm using web-ext for addon development and something broke my IndexedDB simply by reloading the addon I was working on. My addon is only opening and reading the IndexedDB when it's opened so it's strange it could get corrupted like that.

STR:

1. load the attached Firefox profile into Firefox ESR 102 (it's testing blank profile without any private info with single addon installed, and with broken IndexedDB)
   It has 44MB so download it from here:
   https://mega.nz/file/lH521ajI#58OOvgwLOxpRcJspxsNEIzYSHu6dZ9PRZpItY-RDqvc

2. open browser console: "Ctrl + Shift + J"

3. open New tab, that should open "Group Speed Dial" addon page

4. observe error in the browser console
   4b. Alternatively, you can open console window on the dials page (Ctrl + Shift + K) and execute this code that opens DB and tries to read some images:

(async () => {
  const DB_NAME = "group_speed_dial";
  const DB_VERSION = 9;
  const DB_TABLE = {DB_IMAGE: "image"};
  const DB_INDEX = {GROUP_INDEX: "groupIndex"};

  class MainDB {
    constructor(name, version) {
      this.name = name;
      this.version = version;
      this.promise = this.open();
    }

    async open() {
      return this.promise = new Promise((resolve, reject) => {
        const DBOpenRequest = self.indexedDB.open(this.name, this.version);
        DBOpenRequest.onupgradeneeded = e => {
          console.log('DB: onupgradeneeded');
          const db = DBOpenRequest.result;
          db.onerror = db.onabort = reject;
          if (!db.objectStoreNames.contains(DB_TABLE.DB_IMAGE)) db.createObjectStore(DB_TABLE.DB_IMAGE, { keyPath: ['url', 'group'] });
          const store = DBOpenRequest.transaction.objectStore(DB_TABLE.DB_IMAGE);
          if (!store.indexNames.contains(DB_INDEX.GROUP_INDEX)) store.createIndex(DB_INDEX.GROUP_INDEX, DB_INDEX.GROUP_INDEX, { unique: false });
        };

        DBOpenRequest.onerror = reject;
        DBOpenRequest.onsuccess = () => {
          const db = DBOpenRequest.result;
          db.addEventListener('close', () => console.log(`DB: closed unexpectedly`));
          resolve(db);
        };
      });
    }

    static async withDB(callback) {
      const mainDb = new MainDB(DB_NAME, DB_VERSION);
      const db = await mainDb.promise;
      return callback(mainDb).finally(() => db.close());
    }
  }

  return MainDB.withDB(async dbHelper => {
    // query all images in the "image" database
    const images = await new Promise(async (resolve, reject) => {
      const images = [];
      const db = await dbHelper.promise;
      const store = db.transaction([DB_TABLE.DB_IMAGE]).objectStore(DB_TABLE.DB_IMAGE);
      store.onerror = reject;
      const openCursor = store.openCursor();
      openCursor.onerror = reject;
      openCursor.onsuccess = e => {
        const cursor = e.target.result;
        if (cursor) {
          images.push(cursor.value);
          cursor.continue();
        }
        else resolve(images);
      };
    });
    return images;
  });
})().then(console.log, console.error);

Actual results:

In the browser console you can see the error:

 IndexedDB UnknownErr: ActorsParent.cpp:5653 

Expected results:

As I've mentioned before, this is a blank new profile created by web-ext that got database corruption after being reloaded several times.

And I've seen it several times before, but not that long ago. I'm pretty sure some IndexedDB changes were merged into Firefox ESR 102 that caused this. I'm also getting similar reports from the users of my addon.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Storage: IndexedDB' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jens Stutte [:jstutte]]

Looking at the ESR 102 code the UnknownErr seems to come from here and that code seems to have changed in 103 due to bug 1773088. Did you test with newer versions how they behave?

Thanks for your support!

Comment 3

[juraj.masiar]

The reports I'm getting are from release channel, for example 115, 116. So the database is getting corrupted even in recent versions.
But I'm developing only using ESR 102.

In any case, once the DB is corrupted (like in the profile I've uploaded), it stays corrupted.
Upgrading profile to 117 (Developer Edition) won't fix that. But it will generate a slightly different error: IndexedDB UnknownErr: ActorsParent.cpp:5384.

In any case - could you check the IndexedDB in the profile that I've uploaded and see why the DB is corrupted?
It should be stored here:

firefox-profileyw577c/storage/default/moz-extension+++5a4637aa-056d-444c-ac86-ffbfd53ae6e1/

Comment 4

[Jens Stutte [:jstutte]]

FWIW, it's always at the same point.

Jan, would you mind to take a look?

Comment 5

[Jan Varga [:janv]]

Is there any chance that the database contains references to the MutableFile/FileHandle objects ?

Comment 6

[juraj.masiar]

I'm not sure what those are :), but the database contains blobs.
Each record in the "image" table will usually contain one blob for thumbnail and one blob for favicon.

Comment 7

[Jan Varga [:janv]]

Ok, so just normal DOM blobs or DOM Files.

Comment 8

[juraj.masiar]

Yes, normal DOM blobs, all created during the import using (await fetch(base64Image)).blob(), some maybe later using canvas API.

Comment 9

[Jan Varga [:janv]]

Ok, the next thing we could do here is to check if there are any relevant warnings in the browser console. Could you check if there are any QM_TRY warnings in the console ?

You could also try to run a debug build which should give us more debugging information about the failure.

Comment 10

[juraj.masiar]

Oh man, I'm just an addon developer, I have no idea how to get or run a debug build and where to look for what information :).
I did uploaded the whole profile here so maybe you can test it :) (I realize you must be busy, but what programmer isn't :))
The issue will reproduce the moment you open new tab. This is really an amazing piece of broken database - it's unused, the profile is fresh, all settings in the defaults and yet a total DB corruption that forces user to reinstall the addon to fix it (and to loose data stored there).

Comment 11

[juraj.masiar]

Just a short update, the bug appeared today again using the new Firefox ESR (115.4.0esr).

IndexedDB UnknownErr: ActorsParent.cpp:5432

Affected new profile is here:
https://mega.nz/file/cGQgDRIA#d1wyM-3_ktYDXRvvDJgiPfA_QmB1PjfNwZbKRlYLR34

SRT: load profile and open new tab

Comment 12

[Jan Varga [:janv]]

Sorry for the inactivity. Do you still experience the problem?
Unfortunately, we no longer have access to the profiles.

Comment 13

[juraj.masiar]

Yeah, I've deleted them recently because I wasn't sure anymore whether it contained some sensitive data or not.
But the bug is still there, I've seen it in Nightly few weeks ago.
I'll make a profile copy again next time I see it.

Comment 14

[Jan Varga [:janv]]

Ok, thanks.

Comment 15

[juraj.masiar]

Attachment: IndexedDB exception type

Hello Jan,
Here is the most recent incident info, let me summarize my case so that you have a full picture:

• I'm developing Group Speed Dial extension in Firefox Nightly, currently I'm running 146.0a1 (2025-10-26)
• I'm using web-ext which always creates fresh new Firefox Nightly profile
• I'm not restarting my PC, I put it to sleep every day, so my Nightly runs for several days (but with minimum activity)
• sometimes, usually after some days, the IndexedDB will break and stays broken (even when developing other extensions!)
• the extension is loaded as Temporary Extension

Here is the affected profile from my temp folder:
https://mega.nz/file/NDhXVIaB#3AsC44LPntpfLVD0W1OQ2ErvmbjAeio2C5FFsKQm4V0
The affected extension UUID is "135d3371-7585-4f87-8f29-772a3e123c6d".

The errors I see in the Multiprocess Browser Console when loading extension page that access IndexedDB:

NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIFaviconService.setFaviconForPage]
    setIconFromLink resource:///actors/LinkHandlerParent.sys.mjs:142
    receiveMessage resource:///actors/LinkHandlerParent.sys.mjs:55
LinkHandlerParent.sys.mjs:151:17
    setIconFromLink resource:///actors/LinkHandlerParent.sys.mjs:151
    receiveMessage resource:///actors/LinkHandlerParent.sys.mjs:55
NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIFaviconService.setFaviconForPage]
    setIconFromLink resource:///actors/LinkHandlerParent.sys.mjs:142
    receiveMessage resource:///actors/LinkHandlerParent.sys.mjs:55
LinkHandlerParent.sys.mjs:151:17
    setIconFromLink resource:///actors/LinkHandlerParent.sys.mjs:151
    receiveMessage resource:///actors/LinkHandlerParent.sys.mjs:55
IndexedDB UnknownErr: ActorsParent.cpp:5574 

The error handlers in my extension then reports errors only the general error: UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code. (see also attached screenshot).

BTW: see also bug 1979997.

Comment 16

[juraj.masiar]

Quick update - it happened again, in newer Firefox 147.0a1 (2025-11-12), this time on a line 5573:

 IndexedDB UnknownErr: ActorsParent.cpp:5573 

Comment 17

[Jan Varga [:janv]]

Thanks for providing the date as well (not just FF version). So the line is:
https://hg-edge.mozilla.org/mozilla-central/file/051bafeb3aedcd9c81ba9ba9a1f8b46044fb4e09/dom/indexedDB/ActorsParent.cpp#l5573

The comment says "This can only fail if the child has crashed", but it's unclear if that's the case for real.

Comment 18

[juraj.masiar]

Can I maybe debug it somehow to see a better error?
My Firefox is still running and the error is now persistently present with each page reload.

Comment 19

[Jan Varga [:janv]]

Yes, running a debug build with a copy of <profile>/storage and <profile>/storage.sqlite would give you much more information.
I don't now if you have experience with that (either building your own FF locally or downloading a debug build).
In any case, I can give you more details, just let me know what would you prefer.
A local build can be even more helpful because you can add some debugging printfs, etc.

Comment 20

[juraj.masiar]

Hello Jan,
Could you please look into this?

I have prepared for you super simple and easy to reproduce example of a fresh empty profile with almost empty but partially broken IndexedDB database.
You can run it locally using Firefox Nightly and the issue will be 100% be present and easy to see as IndexedDB UnknownErr: ActorsParent.cpp:5563, also known as "UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code.".
But you will need to install Mozilla web-ext tool if you don't have it yet:

npm install --global web-ext

STR:

1. download and uzip:
   https://mega.nz/file/BfpVzbAZ#kRNeFGvIC1AZSRLHO-T8e8EDpm9NcZqMHBpvtzRkPxY
2. open terminal in the unzipped folder and execute:

cd ./firefox_dev
web-ext run --firefox=nightly --firefox-profile="../firefox-profilekHn9lN"

(instead of "nightly" you can specify absolute path for your Firefox binary)

3. Firefox Nightly will open with "Group Speed Dial" addon loaded and it will show an error message
4. the ActorsParent.cpp:5563 error will be already in the browser console, and it will trow also if you manually try to inspect the IndexedDB on the Storage tab / Indexed DB / moz-extensions://... / group_speed_dial / "image" table - clicking this table will break the inspector completely

Comment 21

[juraj.masiar]

Attachment: video STR Indexeddb.mp4

Here, I'm uploading also a short 2 min. video of the STR above with my commentary so that you see what is this about.

Comment 22

[Jari Jalkanen [:jari]]

Attachment: Bug 1849842: Handle temporary wal locking race condition error. r=#dom-storage,mak

Comment 23

[Jari Jalkanen [:jari]]

Attachment: Stack trace

Comment 24

[Jan Varga [:janv]]

Ok

Comment 25

[Jari Jalkanen [:jari]]

I generated the (artificial) stack trace above to sheds light on what's going on. Seems like it's an uncommon sqlite3 error related to WAL locking race which is handled as unknown error but can be handled via retry like a busy error. It was reproducible only on Windows but technically it should be platform agnostic.

Comment 26

[Jan Varga [:janv]]

Nice to see this getting a priority.

Comment 27

[Jan Varga [:janv]]

Given this has a new owner, clearing needinfo.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/97cff897eb47
https://hg.mozilla.org/integration/autoland/rev/09f4e2c06efe
Handle temporary wal locking race condition error. r=mak

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ac3c722d64f3
https://hg.mozilla.org/integration/autoland/rev/37b7f282b846
Revert "Bug 1849842: Handle temporary wal locking race condition error. r=mak" for causing failures at test_storage_service.js.

Comment 30

[Atila Butkovits]

Backed out for causing failures at test_storage_service.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/37b7f282b846

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2C24.04%2Cdebug%2Cxpcshell%2Ctests%2Ctest-linux2404-64%2Fdebug-xpcshell%2Cx&revision=09f4e2c06efe963959e499fd228e2231f235bb28&selectedTaskRun=avBVRRvNSI21hdvRjnFOIg.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=571262370&repo=autoland&task=avBVRRvNSI21hdvRjnFOIg.0&lineNumber=8061

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1eee5b6fb8ed
https://hg.mozilla.org/integration/autoland/rev/4aad2eec1256
Handle temporary wal locking race condition error. r=mak

Comment 32

[rperta]

https://hg.mozilla.org/mozilla-central/rev/4aad2eec1256

Comment 33

[juraj.masiar]

So, what does the fix do?
When loading the example profile from my comment #20 in the current Nightly 154.0a1 (2026-06-16), the database is still broken, with error in browser console:

IndexedDB UnknownErr in operator(): \builds\worker\checkouts\gecko\dom\indexedDB\ActorsParent.cpp:5622

Or should the fix prevent breaking the profile database in the first place and this specific IndexedDB is now permanently corrupted?

Comment 34

[juraj.masiar]

Is the fix actually targeting my other bug 2044020? :)
Because it's definitely affecting it, but these two bugs are completely unrelated, even though they affect the same app.

This bug is old and it's about permanently breaking IndexedDB.
The bug 2044020 is a recent regression in Firefox 149 that only temporarily breaks IndexedDB and causes 10s delay.