1378796 - Use fallible allocation for the profile buffer

Status: NEW

(Core :: Gecko Profiler, defect, P3)

Description

[Craig]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170504112025

Steps to reproduce:

Use Firefox for about a day. It becomes noticeably sluggish.
(Use google streetview and that sluggishness may only take minutes.)
click Tools/Web Developer/Performance
click Start Recording Performance


Actual results:

Firefox crashes

Comment 1

[Greg Tatum [:gregtatum]]

I didn't follow up on this bug when it was filed, as I didn't know what to do with it. I assume this is something in the Gecko Profiler. Is there anything actionable on this mstange, or should I just close it?

Comment 2

[Markus Stange [:mstange]]

Craig, are you still experiencing this? If you are still getting crashes, can you find links to the crash reports on about:crashes and paste them into a comment on this bug?

Comment 3

[Craig]

Sure. I didn't know about "about:crashes" before and none of the crash reports have ever managed to be submitted at crash time. (I created a bug report on that too.) However, they submit when I look at them through about:crashes.

This is the most recent one:
https://crash-stats.mozilla.com/report/index/d609e466-b92e-42c6-9aa3-909c20171130

If you'd like more, I find Firefox gets slow enough to reproduce this at least daily.

Comment 4

[Markus Stange [:mstange]]

Thanks! This crash report indicates that you don't have any available memory on the machine. When we start the profiler, we want to allocate some amount of memory for the recording buffer, but the allocation fails. So we crash.

Let's make this bug about allocating the profile buffer using fallible allocation. Doing so won't help the performance on your machine, but it will avoid this particular crash (by refusing to start the profiler instead).

Comment 5

[Craig]

"Available Virtual Memory 	347,799,552 bytes (347.8 MB)
Available Page File 	3,682,234,368 bytes (3.68 GB)"
If FF thinks there's no available memory, there's something very wrong with it.

Comment 6

[Markus Stange [:mstange]]

You're using a 32 bit build, so Firefox can only address 2GB of virtual memory, even if you have more physical memory. And the remaining 347.8 MB of virtual memory are probably so fragmented that there's no contiguous 90MB slice available.
(You're also using Windows XP, which Firefox doesn't support any more, except for ESR security fixes.)

Comment 7

[Craig]

Then why has memory management become so much worse in recent versions? I ran FF28 for a very long time (because the subsequent versions of FF removed the original, better, sync option) before moving to FF40+. FF28 processes got to over 1.5GB and ran without trouble for weeks. Recent versions hit about 1.2GB (according to Windows) and become extremely sluggish, before crashing or having to be forcibly killed with less than a day of use.

Comment 8

[Markus Stange [:mstange]]

I don't know. Can you please file a new bug about the memory usage regression? Let's keep this bug about the profiler crash.

Comment 9

[Craig]

The main reason I filed this bug report is that it's solid, specific and easily reproducible. My browser daily becomes so slow that it's unusable and has to be re-started (usually by killing the process), but that is hard to document and produces no crash log. Starting the performance recorder causes a crash, which is easy to document and produces a crash log. If the easily reproduced and easily tested issue hasn't been looked at for 5 months, I have low expectations of any value in reporting the more general problem.

Comment 10

[Markus Stange [:mstange]]

Bug 1476757 should help with this.