Open Bug 1591164 Opened 5 years ago Updated 1 year ago

Firefox creates corrupt places.sqlite


(Toolkit :: Storage, defect, P5)

70 Branch





(Reporter: alan, Unassigned)



(2 files)

User Agent: Mozilla/5.0 (X11; Linux ppc64le) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36

Steps to reproduce:

Open Firefox on a ppc64el machine.

Actual results:

A message "The bookmarks and history system will not be functional because one of Firefox's files is in use by another application. Some security software can cause this problem." Even after deleting the database and opening Firefox again I get the same message and sqlite3 agrees that the database is corrupt when I try to open it, so it seems that Firefox is creating a corrupt places.sqlite.

Expected results:

My bookmarks and history work.

Severity: normal → critical
Component: Untriaged → Places
Product: Firefox → Toolkit

which Sqlite version do you have in the system? Is Sqlite working properly (can create dbs and so on) from the command line? Could you please try to open places.sqlite file from the Sqlite command line and tell if you can open it and browser its contents?

Flags: needinfo?(alan)

This is in a fresh Ubuntu 19.10 ppc64el install. The libsqlite version is 3.29.0-2 and if I create a new database from the command line it works. If I try to open places.sqlite with the command line and list the tables it says "Error: database disk image is malformed."

Flags: needinfo?(alan)
Attached file places.sqlite

A broken places.sqlite.

Could you please try creating this boolean pref and flipping it to true?

Does it change anything?

Flags: needinfo?(alan)

I created that flag as true, but it didn't change anything. The same message appears in the browser and the places.sqlite database is still corrupt according to the sqlite command line.

Flags: needinfo?(alan)

Sorry, I forgot to tell after flipping the pref you should close firefox, delete places.sqlite and favicons.sqlite, and start firefox.
Are you also removing favicons.sqlite when you remove places.sqlite? Are you also removing all places.sqlite.wal files?

Flags: needinfo?(alan)

There were no .wal files, but after closing Firefox I removed both places.sqlite and favicons.sqlite. I got the same message and corrupt databases.

Flags: needinfo?(alan)

It would probably be useful to run a debug build and copy any output logs from the console, it may tell us where we are failing.
Unfortunately we don't have such builds, I don't have a ppc64 machine, and afaik ppc64 is directly supported by Debian (not a Mozilla tier1), so it would be better to ask them, I don't know what's the status of that build.
You could try to compile Firefox by yourself in debug mode ( but it may take time.

The best options to get support are:

  1. try with firefox-esr instead of firefox
  2. ask in Ubuntu forums
  3. ask to the firefox package maintainer

I'll needinfo Glandium that I think is still part of the debian maintainers for firefox, he may know how to proceed.

Ever confirmed: true
Flags: needinfo?(mh+mozilla)
OS: Unspecified → Linux
Priority: -- → P5
Hardware: Unspecified → Other

Ubuntu doesn't use the same build configuration as Debian, so I can't tell much here. Redirecting to Chris.

Flags: needinfo?(mh+mozilla) → needinfo?(chrisccoulson)

The "Output of 'mach run' on a fresh profile." attachment to this bug is from a build with

ac_add_options --disable-optimize
ac_add_options --enable-debug

in the mozconfig. Since this a distro specific bug I'll take it to the Ubuntu forums, but if there are more questions here I'm happy to do what I can to answer them.

You are right, I missed the log, I'm sorry.
From the log it's evident that all the tries to use database connections are failing, I see various failures also in the Permission and Cookies components. It's possible the libsqlite is not compiled with all the required options, that is strange though, because in such a case we should immediately assert on startup.
If you find that an sqlite option is missing, we can add a check on startup for it, so that this doesn't happen again.

I'll move this to Storage because it seems more general than just history.

Component: Places → Storage

we don't use anymore system sqlite so potentially this shouldn't happen, feel free to reopen if you still have problems.

Closed: 4 years ago
Flags: needinfo?(chrisccoulson)
Resolution: --- → WORKSFORME

Hello, I'm a new subscriber and I came to you to tell you that this annoying and hateful Firefox bug, related to the history is still present and as far as I'm seeing it is only since Ubuntu 19.04 when I first saw it. I also tried to follow the Firefox guide which says to delete some files and restart but the problem persists. I also tried to deactivate, through the advice of a colleague who also uses Power as an architecture, to also deactivate the part that deals with security on Ubuntu but there is nothing to do, the problem persists and persists for years now and only and exclusively on Ubuntu, other distros don't have this problem. Is it possible that after years we have not been able to understand why this conflict must be created between the Ubuntu security software and the Firefox history ???? !!!

I want to add that this is still happening for me, but I was building my own Firefox so I didn't get around to reopening this bug.

Resolution: WORKSFORME → ---

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --

this still happens on ppc64le with ubuntu 22.04.1 LTS and (at least) firefox 103.0 and firefox 104.0.2, the last firefox that I know didn't have this issue is 61.0.2.

It may actually be an upstream Sqlite problem, it assumes the byte order is big endian on ppc, there is some discussion in
This is not a tier1 platform, thus it's community maintained for the most part. I don't think there's a working ppc64le build atm.

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)
Severity: -- → S4
Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.