Firefox crash [@ OOM | small ]

RESOLVED DUPLICATE of bug 1190258

Status

()

--
critical
RESOLVED DUPLICATE of bug 1190258
4 years ago
2 years ago

People

(Reporter: helpdeskivc, Unassigned)

Tracking

38 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink], crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

495.76 KB, application/x-gzip
Details
(Reporter)

Description

4 years ago
I have a big problem with my Firefox browser, I don allow me work
every time its crashed, I must close and reopen it

Version 	38.0.5
Build ID 	20150525141253
Crash Reason 	EXCEPTION_BREAKPOINT
Crash Address 	0x735f1aa1

Updated

4 years ago
Group: core-security
Component: Developer Tools: Scratchpad → Untriaged

Comment 1

4 years ago
You shouldn't send private emails to people with information about a bug. It limits the number of people that see the information and doesn't record it in the bug. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines for more help on how to file a good bug.

That being said bp-dc36d6bd-9b65-4597-8c46-1a42f2150624 is an [@ OOM | small ] crash.
Crash Signature: [@ OOM | small ]
Summary: 20150525141253 → Crash [@ OOM | small ]
"OOM" means "Out Of Memory". You appear to have more memory available than the size of the allocation that failed, but perhaps Windows rejected the request because some other resource has run out? Getting down to 80Mb memory left doesn't give Windows a lot of headroom to do the things it does. Do you have a lot of other things running on your machine at the same time? do you have a lot of Firefox windows or tabs open?

Comment 3

4 years ago
System Memory Use Percentage: 97

Although it's weird that there's pagefile still: Available Page File: 1630715904

dmajor, are there any other clues or steps to help with this?
Flags: needinfo?(dmajor)
On a 32-bit operating system, Firefox is only able to use 2GB of memory. It's easy to reach the limit. Using fewer tabs, or closing the browser frequently, may help a little bit.
Flags: needinfo?(dmajor)
How many tabs were open?
Flags: needinfo?(helpdeskivc)
Summary: Crash [@ OOM | small ] → Firefox crash [@ OOM | small ]

Comment 6

3 years ago
I have this same crash, but on 64-bit (!) FireFox (Nightly 42):

https://crash-stats.mozilla.com/report/index/e9b66bf7-cd6b-4dac-8a48-3f5d42150728

64-bit browser should not have OOM crashes, but it does.

Comment 7

3 years ago
(In reply to User Dderss from comment #6)
> I have this same crash, but on 64-bit (!) FireFox (Nightly 42):
> 
> https://crash-stats.mozilla.com/report/index/e9b66bf7-cd6b-4dac-8a48-
> 3f5d42150728
> 
> 64-bit browser should not have OOM crashes, but it does.

Benjamin, any idea what's going on here? (I'm sorry if you're not the right person to ask, please feel free to redirect.)
Flags: needinfo?(benjamin)
> > https://crash-stats.mozilla.com/report/index/e9b66bf7-cd6b-4dac-8a48-3f5d42150728
> > 
> > 64-bit browser should not have OOM crashes, but it does.

The system ran out of page file (64-bit won't help with that). The Firefox process was using something like 15 GB of memory. I'm sure the MemShrink team would love to see an about:memory report the next time it goes that high.
Flags: needinfo?(benjamin)

Comment 9

3 years ago
Yes, this is physical OOM issue.

Since the time of that crash report I have noticed that FireFox nightly became exploding when whatching YouTube videos serially.

Closing watched video and even erasing history of closed tabs does not free occupied memory, it just continues to grow until death.

This was not the case just a week or two ago, but something has happened to Nightly build so in uncertain circumstances it can not release memory any more.
> Since the time of that crash report I have noticed that FireFox nightly
> became exploding when whatching YouTube videos serially.
> 
> Closing watched video and even erasing history of closed tabs does not free
> occupied memory, it just continues to grow until death.
> 
> This was not the case just a week or two ago, but something has happened to
> Nightly build so in uncertain circumstances it can not release memory any
> more.

Anthony, could your team look into this?
Flags: needinfo?(ajones)

Comment 11

3 years ago
Created attachment 8642494 [details]
memory-report.json.gz

Here is memory report from my current session. It is not close to death yet, but FF already occupies close 10 GB, which was not like that at all couple of weeks ago for the pattern of use I have.
See but 1190530 for a similar report.

Updated

3 years ago
Attachment #8642494 - Attachment is obsolete: true

Comment 13

3 years ago
Created attachment 8642590 [details]
memory-report.json.gz

This is FireFox Nightly 42 session that now grew to 13 GB; soon to die.
11,027.73 MB (100.0%) -- explicit
├───8,899.40 MB (80.70%) ── heap-unclassified

This is very likely to be the same issue as bug 1190530 and/or bug 1189194.

Comment 15

3 years ago
Thanks; it is interesting what exactly has happened to the Nightly code that inflicted such a wide failure that destroyed normal working of several important things.

Comment 16

3 years ago
Youtube seems to be a good example here. I make nothing as to to write here and memory is growing during youtube is playing. Time for a restart.


1,274.94 MB (100.0%) -- explicit
├────804.20 MB (63.08%) ── heap-unclassified

    0.00 MB ── d3d11-shared-textures
    0.00 MB ── d3d9-shared-texture
    0.00 MB ── d3d9-shared-textures
    0.00 MB ── d3d9-surface-image
    0.00 MB ── gfx-d2d-vram-draw-target
    0.00 MB ── gfx-d2d-vram-source-surface
   10.32 MB ── gfx-surface-win32
    0.00 MB ── gfx-textures
    0.00 MB ── gfx-tiles-waste
          0 ── ghost-windows
    0.00 MB ── gpu-committed
    0.00 MB ── gpu-dedicated
    0.00 MB ── gpu-shared
1,044.41 MB ── heap-allocated
      1,103 ── heap-chunks
    1.00 MB ── heap-chunksize
1,053.40 MB ── heap-committed
1,103.00 MB ── heap-mapped
      0.86% ── heap-overhead-ratio
          1 ── host-object-urls
    2.60 MB ── imagelib-surface-cache-estimated-locked
    6.83 MB ── imagelib-surface-cache-estimated-total
          0 ── imagelib-surface-cache-overflow-count
    1.64 MB ── js-main-runtime-temporary-peak
          0 ── low-commit-space-events
1,345.63 MB ── private
1,092.61 MB ── resident
1,740.01 MB ── vsize
   63.49 MB ── vsize-max-contiguous
Whiteboard: [MemShrink]

Comment 18

3 years ago
Confirmed. It is fixed with todays nightly. Memory consumption is stable during youtube playing.

121.55 MB (21.29%) ── heap-unclassified

    0.00 MB ── canvas-2d-pixels
    0.00 MB ── d3d11-shared-textures
    0.00 MB ── d3d9-shared-texture
    0.00 MB ── d3d9-shared-textures
    0.00 MB ── d3d9-surface-image
    0.00 MB ── gfx-d2d-vram-draw-target
    0.00 MB ── gfx-d2d-vram-source-surface
   20.57 MB ── gfx-surface-win32
    0.00 MB ── gfx-textures
    0.00 MB ── gfx-tiles-waste
          0 ── ghost-windows
    0.00 MB ── gpu-committed
    0.00 MB ── gpu-dedicated
    0.00 MB ── gpu-shared
  354.71 MB ── heap-allocated
        455 ── heap-chunks
    1.00 MB ── heap-chunksize
  361.27 MB ── heap-committed
  455.00 MB ── heap-mapped
      1.85% ── heap-overhead-ratio
          2 ── host-object-urls
    2.74 MB ── imagelib-surface-cache-estimated-locked
    3.00 MB ── imagelib-surface-cache-estimated-total
          0 ── imagelib-surface-cache-overflow-count
    1.65 MB ── js-main-runtime-temporary-peak
          0 ── low-commit-space-events
  677.30 MB ── private
  613.07 MB ── resident
1,182.67 MB ── vsize
  128.69 MB ── vsize-max-contiguous
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(ajones)
Resolution: --- → DUPLICATE
Duplicate of bug: 1190258

Updated

2 years ago
Flags: needinfo?(helpdeskivc)
You need to log in before you can comment on or make changes to this bug.