Closed
Bug 1015683
Opened 10 years ago
Closed 10 years ago
crash in mozilla::layers::BasicCompositor::BeginFrame
Categories
(Core :: Graphics: Layers, defect)
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.
Reporter | ||
Comment 2•10 years ago
|
||
(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.
Reporter | ||
Comment 3•10 years ago
|
||
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?
Reporter | ||
Comment 5•10 years ago
|
||
(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.
Reporter | ||
Comment 6•10 years ago
|
||
(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
Reporter | ||
Comment 7•10 years ago
|
||
.. 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!
Updated•10 years ago
|
Version: unspecified → 33 Branch
Comment 10•10 years ago
|
||
This is the 6th top crasher among sessions attempting D3D11 layers.
Blocks: 1061693
Comment 11•10 years ago
|
||
I think this is fixed (unless the signature moved). This crash was last seen on nightly build 20140724030201.
Comment 12•10 years ago
|
||
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
Comment 13•10 years ago
|
||
[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.
status-firefox32:
--- → unaffected
status-firefox33:
--- → affected
status-firefox34:
--- → unaffected
status-firefox35:
--- → unaffected
tracking-firefox33:
--- → ?
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
(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)
Comment 17•10 years ago
|
||
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)
Comment 18•10 years ago
|
||
(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.
Comment 19•10 years ago
|
||
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)
Comment 20•10 years ago
|
||
What fixed this is bug 1037226. It landed July 24. Let's uplift it.
Comment 21•10 years ago
|
||
(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.
Description
•