Closed Bug 1015683 Opened 10 years ago Closed 10 years ago

crash in mozilla::layers::BasicCompositor::BeginFrame

Categories

(Core :: Graphics: Layers, defect)

33 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1037226
Tracking Status
firefox32 --- unaffected
firefox33 + affected
firefox34 --- unaffected
firefox35 --- unaffected

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [regression?])

Crash Data

firefox virtual memory usage on vista was 1GB and growing, but 1GB should not be enough to crash. 

These crashes started with 2014-05-20 build and only version 32 nightly according to https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Alayers%3A%3ABasicCompositor%3A%3ABeginFrame%28nsIntRegion+const%26%2C+mozilla%3A%3Agfx%3A%3ARectTyped%3Cmozilla%3A%3Agfx%3A%3AUnknownUnits%3E+const*%2C+mozilla%3A%3Agfx%3A%3AMatrix+const%26%2C+mozilla%3A%3Agfx%3A%3ARectTyped%3Cmozilla%3A%3Agfx%3A%3AUnknownUnits%3E+const%26%2C+mozilla%3A%3Agfx%3A%3ARectTyped%3Cmozilla%3A%3Agfx%3A%3A...&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&version=Firefox%3A32.0a1&version=Firefox%3A31.0a2&version=Firefox%3A30.0b&hang_type=any&date=2014-05-25+01%3A00%3A00&range_value=2#reports

Also, in recent days windows has complained a few times "your computer is low on memory", and that I should close (firefox) nightly. but I am not low on windows memory. And the timing is roughly consistent with these crashes starting per socorro

Regression??

bp-b293acba-7339-4428-aca0-41d522140525.
=============================================================
0	xul.dll	mozilla::layers::BasicCompositor::BeginFrame(nsIntRegion const &,mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const *,mozilla::gfx::Matrix const &,mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const &,mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> *,mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> *)	gfx/layers/basic/BasicCompositor.cpp
1	xul.dll	mozilla::layers::LayerManagerComposite::Render()	gfx/layers/composite/LayerManagerComposite.cpp
2	xul.dll	mozilla::layers::LayerManagerComposite::EndTransaction(void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,mozilla::layers::DrawRegionClip,nsIntRegion const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags)	gfx/layers/composite/LayerManagerComposite.cpp
3	xul.dll	mozilla::layers::LayerManagerComposite::EndEmptyTransaction(mozilla::layers::LayerManager::EndTransactionFlags)	gfx/layers/composite/LayerManagerComposite.cpp
4	xul.dll	mozilla::layers::CompositorParent::CompositeToTarget(mozilla::gfx::DrawTarget *)	gfx/layers/ipc/CompositorParent.cpp
5	xul.dll	mozilla::layers::CompositorParent::Composite()	gfx/layers/ipc/CompositorParent.cpp
6	xul.dll	MessageLoop::RunTask(Task *)	ipc/chromium/src/base/message_loop.cc
7	xul.dll	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)	ipc/chromium/src/base/message_loop.cc
8	xul.dll	MessageLoop::DoWork()	ipc/chromium/src/base/message_loop.cc
9	xul.dll	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)	ipc/chromium/src/base/message_pump_default.cc
10	xul.dll	MessageLoop::RunHandler()	ipc/chromium/src/base/message_loop.cc
11	xul.dll	MessageLoop::Run()	ipc/chromium/src/base/message_loop.cc
12	xul.dll	base::Thread::ThreadMain()	ipc/chromium/src/base/thread.cc
13	xul.dll	`anonymous namespace'::ThreadFunc(void *)	ipc/chromium/src/base/platform_thread_win.cc 

Furthermore, same crash signature occurred for me yesterday with Thunderbird 
bp-779fbf73-8766-4e7f-8dca-d61252140524  - so far mine is the only crash recorded for Thunderbird users
> These crashes started with 2014-05-20 build and only version 32 nightly
That's about the date when OMTC was enabled.

> but I am not low on windows memory.
Your crash reports show 400-500MB pagefile remaining. While that's not horribly low, it is low enough to start worrying. Other users' reports are generally showing either low pagefile or low available VM.

This code might just be one of the first things to fail at high memory usage.
(In reply to David Major [:dmajor] (UTC+12) from comment #1)
> > These crashes started with 2014-05-20 build and only version 32 nightly
> That's about the date when OMTC was enabled.

right - bug 899785?

I've since set layers.offmainthreadcomposition.enabled false

> > but I am not low on windows memory.
> Your crash reports show 400-500MB pagefile remaining. While that's not
> horribly low, it is low enough to start worrying. Other users' reports are
> generally showing either low pagefile or low available VM.

Not abnormal for me - 3GB real mem installed, typically using ~2-2.5GB, pagefile is 2.5GB, allowed to grow

N.B. I have 3GB switch enabled on vista, so the firefox process should be able to grow well beyond 2GB before I get into trouble. I also crashed well before that.

> This code might just be one of the first things to fail at high memory usage.

Perhaps. But I've been in much, much higher memory usage without difficulty.
I crashed again bp-53b40221-3c02-4674-8874-c8e732140623

also response time/performance is generally poor. perhaps related?
You likely ran out of address space in that one. Do you get these crashes pretty regularly? Want to be a guinea pig for bug 1007534?
(In reply to David Major [:dmajor] from comment #4)
> You likely ran out of address space in that one. Do you get these crashes
> pretty regularly? Want to be a guinea pig for bug 1007534?

happy to help. Let me know what you need. I'm crashing only an average of once a week. However, I can probably force a crash or two if necessary.
(In reply to David Major [:dmajor] from comment #4)
> You likely ran out of address space in that one bp-53b40221-3c02-4674-8874-c8e732140623. 

p.s. I have /3gb set in my system, so ...
Total Virtual Memory	3221094400
Available Virtual Memory 245223424

I rarely exceed 1.5gb work set, and peak work set, per windows task manager
.. and what I typically see is 2.1gb peak work set
I'm afraid 245MB available VM is well within the danger zone. Our allocators need contiguous 1MB chunks at 1MB-aligned addresses, and we start to run out of those below 300MB. Working set is ok as an estimate, but the true used-VM will always be larger.

Keep an eye on bug 1005844. We ought to be able to bring the failure threshold down a little, but we'll never be able to use every last byte.

I'll ping you when 1007534 is ready for testing, thanks!
Version: unspecified → 33 Branch
This is the 6th top crasher among sessions attempting D3D11 layers.
Blocks: 1061693
I think this is fixed (unless the signature moved). This crash was last seen on nightly build 20140724030201.
Closing per comment 11. I checked again and there still hasn't been any instance of this crash since July 24th. Feel free to reopen if it shows up again.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
[Tracking Requested - why for this release]:
This is still the highest-volume graphics crash in 33 Beta, though, even it seems to not appear in newer trains. Right now it reports in as the #3 topcrash with somewhat over 4% of all our crashes in 33 Beta.
Comment 13 sounds like we might need to backport something? Nical, could it be some of your recent crash-fixing patches that needs backporting?
Flags: needinfo?(nical.bugzilla)
(In reply to Benoit Jacob [:bjacob] from comment #14)
> Comment 13 sounds like we might need to backport something? Nical, could it
> be some of your recent crash-fixing patches that needs backporting?

Unfortunately I don't know what change fixed this. I have been focusing on D3D11-specific stuff lately (and a tiny bit of D3D9).
Flags: needinfo?(nical.bugzilla)
Top crash, still affecting 33. Tracking.
Looks like nobody wants to take this but this is still the largest GFX issue in 33 Beta. Milan, can you find someone to take this one?
Flags: needinfo?(milan)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #17)
> Looks like nobody wants to take this but this is still the largest GFX issue
> in 33 Beta. Milan, can you find someone to take this one?

This seems to be no longer happening on trunk. I wonder (although I'm certainly not sure), whether something else happened on trunk to reduce our memory usage, and that improved this issue. Since this stack is 'new' with OMTC, it's possible we just introduced a new potential OOM point, rather than this crash being related to OMTC itself.
We could try to look at all the changes that went into nightly around 24-25th of July and then got uplifted to Aurora.
Flags: needinfo?(milan)
What fixed this is bug 1037226. It landed July 24. Let's uplift it.
(In reply to Bas Schouten (:bas.schouten) from comment #20)
> What fixed this is bug 1037226. It landed July 24. Let's uplift it.

Good catch! So in this case, this is actually a dupe. I set the appropriate fields over in the other bug so that it actually shows up as a crash bug for this signature.
Resolution: FIXED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.