crash [OOM | small] in mozilla::net::CacheFileMetadata::ReadMetadata (reason: EXCEPTION_BREAKPOINT)

RESOLVED DUPLICATE of bug 1115929

Status

()

Core
Networking: Cache
RESOLVED DUPLICATE of bug 1115929
3 years ago
3 years ago

People

(Reporter: marvinhk, Unassigned)

Tracking

({crash})

35 Branch
x86_64
Windows 7
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

surfing facebook -> open multiple pages in new tabs


Actual results:

crash [OOM | small] in mozilla::net::CacheFileMetadata::ReadMetadata (reason: EXCEPTION_BREAKPOINT), bug report bp-6a3dd2d6-8983-4bcf-a162-ac6be2141225.
(Reporter)

Updated

3 years ago
Crash Signature: [@ OOM | small ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | mozilla::net::CacheFileMetadata::ReadMetadata(mozilla::net::CacheFileMetadataListener*) | mozilla::net::CacheFile::OnFileOpened(mozilla::net:…
Keywords: crash

Comment 1

3 years ago
It doesn't make sense to attribute OOM|small to any function, that's why it has a generic signature for all of those in the first place. It means that we had so little memory available that we ran Out Of Memory (OOM) with a small allocation of <256KB. There's nothing specific to what's at the top of the stack. If you have reliable (!) step to reproduce OOM|small crashes, we are very interested in those, though.
The steps to reproduce are the only interesting thing here, esp. if they work reliably. I'm not sure if we send a memory reports with those crashes right now, but that would also be helpful so we can find out what fills up all the memory.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1115929
You need to log in before you can comment on or make changes to this bug.