Crash in [@ OOM | small]
Categories
(Core :: Storage: IndexedDB, defect, P2)
Tracking
()
People
(Reporter: worcester12345, Unassigned)
References
Details
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0 ID:20200818235255
Crash report: https://crash-stats.mozilla.org/report/index/12b1e743-640a-4645-9366-eb1310200824
Top 10 frames of crashing thread:
0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:54
3 xul.dll snappy::Compress other-licenses/snappy/src/snappy.cc:781
4 xul.dll snappy::RawCompress other-licenses/snappy/src/snappy.cc:1146
5 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::ObjectStoreAddOrPutRequestOp::DoDatabaseWork dom/indexedDB/ActorsParent.cpp:25176
6 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::TransactionDatabaseOperationBase::RunOnConnectionThread dom/indexedDB/ActorsParent.cpp:22749
7 xul.dll mozilla::dom::indexedDB::`anonymous namespace'::TransactionDatabaseOperationBase::Run dom/indexedDB/ActorsParent.cpp:22915
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
9 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:513
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
Hm, there are some new calls in snappy that can result in OOM. Not sure how we can use a fallible allocation here.
|
||
Comment 2•4 years ago
|
||
The signature [@ OOM | small] is absolutely generic and not specific to a particular component.
Also, I don't think this is actionable at all. Small allocation failures indicate an overall low memory condition, so even for the particular crash report it can't be said that there is a root cause in the code it happened to crash. If you happen to have steps to reproduce a situation that leads to an OOM failure, we would be able to check if there is an excessive number of small allocations that accumulate to a huge memory usage.
|
Reporter | |
Comment 3•4 years ago
|
||
Still, a crash is not the way to go. It should give a warning, and then close, or give the option to close. It needs to be more graceful.
|
||
Comment 4•2 years ago
|
||
Only four Firefox crashes in the past month have Snappy on the stack, all 104.0a1 and I suspect all the same person.
- bp-7874f9af-2135-4ae7-9b8d-657000220720
- 480075af-49e6-4526-9a41-929dd0220718
Do you still think this is actionable?
|
||
Comment 5•2 years ago
|
||
(In reply to Worcester12345 from comment #3)
Still, a crash is not the way to go. It should give a warning, and then close, or give the option to close. It needs to be more graceful.
We have the general policy of assuming small allocations to be infallible. They are simply happening too often (also down in third party libraries, as here) in order to be able to do a meaningful error handling all the time (with related computing cost, too). A crash is rude but probably gives us the most information we can get from this situation in order to see if there is anything actionable that goes beyond a random OOM.
(In reply to Wayne Mery (:wsmwk) from comment #4)
Do you still think this is actionable?
I think it never was. Bug 1673778 seems to be a good candidate to dupe this to.
Description
•