uBlock deletes cookies.sqlite upon list update

[Moonchild]

can we get at least some acknowledgement / directions for further troubleshooting / anything?

I don't know what the issue would be when looking at our core code. Nothing significant was changed with the cookie handling between 33.4.x and 33.5.0, I can't reproduce the issue either (I checked my cookie storage and I have cookies going back 3 years... so it was definitely not deleted). If it's an extension then the first thing we need is confirmation which extension it is, then figure out why it happens.

[BenFenner]

I posted in a different thread about losing all of my sessions after updating, and was directed here. Each of my 5 PCs experienced loss of all sessions after updating to Pale Moon 33.5.0 but since then the sessions have remained after shutting down and restarting Pale Moon (and the computer itself in many cases). So I've experienced this once per machine, but not since. (It takes me a while, sometimes months or more to restart Pale Moon, so it took me a while to report back here.)

I wonder if my extensions or privacy settings or other preferences are close to Nuck's, but slightly different.
What I mean is, I'm first wondering if my setting for When Pale Moon starts: Show my windows and tabs from last time is possibly what is letting me hold onto my cookies.sqlite file between launches of Pale Moon...

I'm going to keep an eye on the situation and see if I can come up with any new theories or information.

[RedRamGT]

It might be good to know the environment people are using, that are having the issue.

I am running Windows-7 64-Bit, and Pale Moon Portable 33.5.0.

Add-on's are:
-- Downloads Window 0.6.5
-- GetEmAll! 1.2.4
-- uBlock Origin 1.16.6b1

I upgraded to the 33.5.0 64-Bit SSE2 version, and noticed a few odd things happening with cookies - but nothing consistent or repeatable, it seemed to happen at random. I decided to try the 32-Bit version of 33.5.0, and have not noticed any problems since doing that.

[Nuck-TH]

Seems like only common is uBlock. And some obscure setting/combination of that triggers... something.
Also, i can't reproduce on (almost) clean profile, only on two everyday ones(second was derived from first a while ago)

Seems like i'll have to bisect myself... Sigh.

[gepus]

Seems like only common is uBlock.

IMHO it is nevertheless most unlikely that uBlock has anything to do with it.
By its very nature uBlock doesn't meddle with local files of the browser. It is merely acting as a filtering proxy between your browser and remote servers.

[Nuck-TH]

Seems like only common is uBlock.

IMHO it is nevertheless most unlikely that uBlock has anything to do with it.
By its very nature uBlock doesn't meddle with local files of the browser. It is merely acting as a filtering proxy between your browser and remote servers.

Most of bugs are unlikely, yet they happen. Likeness is not good measure here :\

Fact is that on some specific configurations of profiles running uBlock triggers the problem.
As i written earlier - i spent whole day on my main profile with all extensions disabled and no issue, but after i enabled uBlock - within couple of minutes(not immediately) file got deleted.
Worth noting that it isn't simply deleted, it is some internal mechanism - while .sqlite is deleted, sqlite.bak and .sqlite.bak-rebuild are created.

[Moonchild]

Worth noting that it isn't simply deleted, it is some internal mechanism - while .sqlite is deleted, sqlite.bak and .sqlite.bak-rebuild are created.

That's an important bit of information. This symptom means that the cookies.sqlite database got corrupted by uBlock Origin, was closed for corruption, and queued for being rebuilt. That normally happens at the end of a browsing session but I can imagine it'll fail if secondary corruption occurs if already in that state.
So it does indicate that uBlock Origin causes database corruption; assuming it has more functionality than just "intercepting network requests" here because there's clearly something being done with cookies by the extension, or this wouldn't occur...

[gepus]

Seems like only common is uBlock. And some obscure setting/combination of that triggers... something.
Also, i can't reproduce on (almost) clean profile ...

Did you also test with a new clean profile + only uBlock?
I'd do it with the portable for convenience.

[Nuck-TH]

Seems like only common is uBlock. And some obscure setting/combination of that triggers... something.
Also, i can't reproduce on (almost) clean profile ...

Did you also test with a new clean profile + only uBlock?
I'd do it with the portable for convenience.

Please care o read this thread. It isn't that long

[gepus]

Please care o read this thread. It isn't that long

I did twice.
You checked with two different profiles (almost clean) and with extensions disabled (no issues).
Ergo, my suggestion.

Sorry, but I'm out of further ideas.

[Nuck-TH]

I downgraded to 33.4.1 and at least provisionally can confirm that issue isn't present there with same profile and cookies database file.

[Moonchild]

The only thing I can really think of that touched related code was the code cleanup for mozapps (Issue #2653 (UXP) and Issue #1787 (UXP)) but that shouldn't be relevant for uBlock, I don't think? Maybe it tries to use some of the removed Application interfaces?

[therube]

(I had not yet updated to 33.5.0, was still on 33.4.0.1.
I had previously downloaded the 33.5.0 installer.
As I use the Portable versions, I copied Portable-33.4.0.1 ["instalDir"], wholesale to /Portable-33.5.0/, then unpacked the 33.5.0 installer.exe, deleted existing [Portable] /bin/, & replaced that with contents from 33.5.0 installer. [So in essence, I "created" a 33.5.0 installer.])

Opened 33.5.0 using existing Profile from 33.4.0.1.
Installed uBlock0_1.16.4.30.firefox-legacy.xpi & (manually) updated its' Filters.
Opened www.yahoo.com, saw that uBlock was blocking "stuff".
Quit.

With that, I have cookies.sqlite.bak, which is exactly the same as the cookies.sqlite from before the update from 33.4.0.1 to 33.5.0, & I also have a, cookies.sqlite.bak-rebuild, which I'd assume on (next) browser start up would be renamed to cookies.sqlite.

cookies.sqlite.bak-rebuild, except for .sqlite header data, is entirely nuls ($00$)


I'm thinking it is uBlocks 'Update now' where the issue occurs?
Yes.


Win7 x64, PM 33.5.0 "Portable" x64.


Eh, maybe a silly question, but where is PM's "cookie manager" ?
Oh, Permissions Manager.


If you start with a non-existent cookies.sqlite (& no .bak or such), then the issue does not look to occur.

[LAR Grizzly]

Eh, maybe a silly question, but where is PM's "cookie manager" ?

Quick Link:

chrome://browser/content/preferences/cookies.xul

[therube]

cookies.sqlite (existing from PM 33.4.0.1):

cookies.7z

.
Take existing Profile
Delete any cookies*.* (after having exited PM, of course)
Place above cookies.sqlite into PM
Verify contents...
Quit & Restart PM
Verify no .bak
Update uBlock Filters (Purge caches, then Update now, should suffice)
Verify that you then get a .bak...

[Nuck-TH]

therube, thanks for repeatable and quick method of reproducing the issue!

i spun up bunch of builds(Pale Moon tip of release branch + following UXP commits):

Code: Select all

dcba66d719
25d668395b 
c7f25b6b9a last good
c0b74ce133 first bad

and seems like the culprit is 14b9599104 [js] Avoid potential crash if GC cell is no longer valid. Anyone's guess why...

if anyone want to try - https://ftp2.palemoon.org/avx/test/

[Moonchild]

seems like the culprit is 14b9599104 [js] Avoid potential crash if GC cell is no longer valid. Anyone's guess why...

dwight-schrute-700255536.gif

Well... I guess I'll back that one out then. No idea why that would cause issues.

[Nuck-TH]

Well... I guess I'll back that one out then. No idea why that would cause issues.

Editing that change back in RB_20241204 didn't fix the issue... What?

Update:

Code: Select all

14b9599104 last good?!
c0b74ce133 first bad

How this works?

[Moonchild]

Same deal... no idea why that one would cause issues, as it's just an update to the effective top level domains list. That makes even less sense.

[Sessh]

Sounds like this is a bug in uBlock maybe from it apparently not being maintained? I don't know if that's true, but it hasn't updated in a long time. Seems both the gorhill and UCyborg versions are doing the same thing going by this thread. If the PM commit causing the issue to surface shouldn't do this, it's probable that it's a uBlock issue then?

By the way, am I correct to assume that PM users should be using the UCyborg version (1.16.6b1) and not the gorhill version (1.16.4.30) of uBlock?