1480736 - "The bookmarks and history system will not be functional" even on new profile

Status: RESOLVED INCOMPLETE

(Toolkit :: Places, defect, P5)

Description

[xani666]

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

Steps to reproduce:

Run 62.0b10 (debian experimental package).

I've upgraded from earlier version but it also happens on clean profile/user

it is fine on 61


Actual results:

Crash on the first boot

"The bookmarks and history system will not be functional" on next ones. Whatever was in manual for that bug (why bugs have manuals ? shouldn't they be fixed?) didn't worked.

I've tried to both remove the firefox dir, and run firefox on new user (user with empty home dir) and that only gets that message again. No plugins

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Thanks for reporting the problem and sorry you're experiencing this problem with beta.

Can you try running with a Mozilla-built beta build from https://www.mozilla.org/en-US/firefox/channel/desktop/ and see if that works?  It's possible there's some type of library dependency incompatibility with the way the debian package beta is being built and this will help us quickly rule that out if it's not the problem.

Relatedly, I was thinking maybe something weird could be happening as fallout from bug 1472722, but that only landed in Firefox 63 so shouldn't be impacting the beta.  And also the VFS should be present anyways...

Comment 2

[Marco Bonardo [:mak]]

Usually the problem is a corruption of places.sqlite that we're unable to address automatically. If we find a corrupt we usually try to fix it, if we can't fix it, we set status to locked. The error message is not the best one, I admit.

Could you please try moving places.sqlite from the profile folder to some other backup folder (please store them, we'll need that to debug) and start Firefox without that file? It should generate a new one and import the latest bookmarks backup into it.

Is your profile folder stored locally or on a network share?

Comment 3

[Marco Bonardo [:mak]]

Also, if you could access about:crashes and copy here the link to the latest crash reports, that may be useful.

Comment 4

[xani666]

@Marco as I wrote in bug submission, I had same thing happen when I removed firefox config dir, and when I tried on empty (~ with literally no files in it) user

Sadly I'm not on machine where that happened but I'll try to repeat it monday, I still have profile dir that caused the crash somewhere.

Comment 5

[xani666]

Okay so:

crash after updating to 62, on existing profile: https://crash-stats.mozilla.com/report/index/daf72e66-0b73-430b-afa9-1580f1180810

no crash report when starting from scratch.

62.0b15 from dev channel seems to not have those problems at all so it seems it is something to do with Debian package

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to xani666 from comment #5)
> crash after updating to 62, on existing profile:
> https://crash-stats.mozilla.com/report/index/daf72e66-0b73-430b-afa9-
> 1580f1180810

Thank you for providing this!

Restating: This is from the debian build.  We don't have symbols to find out what's happening in the back-trace.  It might be possible to convert the minidump to a core file and pull the debian symbols from a package and run gdb on it, but that's a bit of work.  (I think Ubuntu uploads their symbols to us though?)

The obvious suspect is always system SQLite, but it looks like although system SQLite is in use, https://packages.debian.org/sid/libsqlite3-0 in unstable (I don't see anything in experimental, so I presume it falls back to unstable) is 3.24.0-1, which is the right version.  Also, the stack traces are able to figure out the module in use, and it's libxul.so all the way, not SQLite.

> no crash report when starting from scratch.
> 
> 62.0b15 from dev channel seems to not have those problems at all so it seems
> it is something to do with Debian package

Thank you for confirming this.  Unfortunately, I'm not sure there's much we can do on our end if the Debian builds are failing but ours are not.  If you can go through the Debian bug-tracker system, they may be able to be of more help especially because I'd hope they could correlate against other crashes reported.  And with that added perspective the relevant Firefox developers may be able to help.

Comment 7

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.