Closed Bug 1134858 Opened 5 years ago Closed 5 years ago

crash with OOM after startup with Tracking Protection enabled

Categories

(Toolkit :: Safe Browsing, defect, critical)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jaws, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-07cfd0a5-db1e-493b-b270-69e3c2150219.
=============================================================

Also https://crash-stats.mozilla.com/report/index/003542fd-98ca-493e-8b75-78e062150219 and https://crash-stats.mozilla.com/report/index/003542fd-98ca-493e-8b75-78e062150219

I was using my normal profile as usual, when all of a sudden while playing a video the browser locked up and then crashed. It now always crashes shortly after startup (about 30 seconds) with OOM.
Gian-Carlo or Monica, what can I do to help you out here? This crash is preventing me from using my default profile.
Flags: needinfo?(mmc)
Flags: needinfo?(gpascutto)
Video of the crash and memory consumption, showing nothing out of the ordinary: http://screencast.com/t/Nqfa92Rdf

Same thing happens when restarting in Safe Mode
Duplicate of this bug: 1134864
Can anyone verify if this bug is happening in release?
I had this happen multiple times nightly.. I disabled the about config tracking protection prefs (via editing my prefs file when crashed) and haven't seen one since.
I sent mail to my Google contacts and pointed them at this bug. FYI, catlee reported on #developers that release was hanging as well. I am trying to get more information on release crashes.
I was not seeing this, but turning on Tracking Protection crashed me almost immediately.  I turned it back off and things are fine again.
re-enabling TP made the problem recur (still nightly) - so its determinstic for me. I'll try release.
Summary: crash with OOM after startup in Safe Browsing → crash with OOM after startup with Tracking Protection enabled
This is not a Google issue, this is ours. It only affects people who have tracking protection enabled, and we pushed a server update today.

For now the workaround is to disable tracking protection. We will figure out how to fix or revert the server.
Flags: needinfo?(mmc)
confirm that it impacts my profile in release too.
I filed bug 1134885 for client-side robustness against broken updates.
Flags: needinfo?(gpascutto)
Duplicate of this bug: 1134879
If I understood the problem correctly, the crashes will stop as soon as the server is fixed and the clients *won't* be stuck with a corrupted database or something like that.

The crashed happened shortly after startup because that's when Firefox probes for updates.
The server rollback is complete and it will take a little while for DNS to catch up after the rollback. Please let me know if this fix didn't work.
Enough people have reported back that the rollback worked that I will mark as fix. There will be a postmortem coming.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1134957
Duplicate of this bug: 1135135
Crash Signature: , nsTArra...] → , nsTArra...] [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | nsTArray_Impl<mozill…
Crash Signature: , unsigned int) | nsTArray_Impl<mozilla::net::nsHttpT... ] → , unsigned int) | nsTArray_Impl<mozilla::net::nsHttpT... ] [@ OOM | large | NS_ABORT_OOM(unsigned long) | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned long, unsigned long) | mozilla::safebrowsing::ChunkSe…
You need to log in before you can comment on or make changes to this bug.