Closed Bug 1342573 Opened 8 years ago Closed 3 years ago

Crash in ARGBSetRow_X86

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
52 Branch
Platform:
x86
Windows
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix

People

(Reporter: philipp, Assigned: jrmuizel)

References

Details

(5 keywords, Whiteboard: [gfx-noted] dupe of 1338771?)

Crash Data

This bug was filed from the Socorro interface and is report bp-a2382900-8755-4978-a7fa-a5c422170224. ============================================================= Crashing Thread (0) Frame Module Signature Source 0 xul.dll ARGBSetRow_X86 media/libyuv/source/row_win.cc:3671 1 xul.dll ARGBRect media/libyuv/source/planar_functions.cc:1263 2 xul.dll mozilla::layers::InitBuffer gfx/layers/BufferTexture.cpp:454 3 xul.dll mozilla::layers::MemoryTextureData::Create(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::SurfaceFormat, mozilla::gfx::BackendType, mozilla::layers::LayersBackend, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags, mozilla::layers::LayersIPCChannel*) gfx/layers/BufferTexture.cpp:488 4 xul.dll mozilla::layers::BufferTextureData::Create(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::SurfaceFormat, mozilla::gfx::BackendType, mozilla::layers::LayersBackend, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags, mozilla::layers::LayersIPCChannel*) gfx/layers/BufferTexture.cpp:122 5 xul.dll mozilla::layers::TextureClient::CreateForRawBufferAccess(mozilla::layers::LayersIPCChannel*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::BackendType, mozilla::layers::LayersBackend, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) gfx/layers/client/TextureClient.cpp:1203 6 xul.dll mozilla::layers::TextureClient::CreateForDrawing(mozilla::layers::TextureForwarder*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::LayersBackend, int, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) gfx/layers/client/TextureClient.cpp:1094 7 xul.dll mozilla::layers::TextureClient::CreateForDrawing(mozilla::layers::KnowsCompositor*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) gfx/layers/client/TextureClient.cpp:995 8 xul.dll mozilla::layers::TextureClient::CreateFromSurface(mozilla::layers::KnowsCompositor*, mozilla::gfx::SourceSurface*, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) gfx/layers/client/TextureClient.cpp:1144 9 xul.dll mozilla::layers::SourceSurfaceImage::GetTextureClient(mozilla::layers::KnowsCompositor*) gfx/layers/ImageContainer.cpp:751 10 xul.dll mozilla::layers::ImageClientSingle::UpdateImage(mozilla::layers::ImageContainer*, unsigned int) gfx/layers/client/ImageClient.cpp:206 11 xul.dll mozilla::layers::ClientImageLayer::RenderLayer() gfx/layers/client/ClientImageLayer.cpp:134 12 xul.dll mozilla::layers::ClientLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) gfx/layers/client/ClientLayerManager.h:375 13 xul.dll mozilla::layers::ClientContainerLayer::RenderLayer() gfx/layers/client/ClientContainerLayer.h:62 14 xul.dll mozilla::layers::ClientLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) gfx/layers/client/ClientLayerManager.h:375 15 xul.dll mozilla::layers::ClientContainerLayer::RenderLayer() gfx/layers/client/ClientContainerLayer.h:62 16 xul.dll mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) gfx/layers/client/ClientLayerManager.cpp:326 17 xul.dll mozilla::layers::ClientLayerManager::EndEmptyTransaction(mozilla::layers::LayerManager::EndTransactionFlags) gfx/layers/client/ClientLayerManager.cpp:406 18 xul.dll PresShell::Paint(nsView*, nsRegion const&, unsigned int) layout/base/nsPresShell.cpp:6341 19 xul.dll nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) view/nsViewManager.cpp:484 20 xul.dll nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) view/nsViewManager.cpp:415 21 xul.dll nsViewManager::ProcessPendingUpdates() view/nsViewManager.cpp:1118 22 xul.dll nsRefreshDriver::Tick(__int64, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:2012 23 xul.dll mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver*, __int64, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:326 24 xul.dll mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) layout/base/nsRefreshDriver.cpp:295 25 xul.dll mozilla::RefreshDriverTimer::Tick(__int64, mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:317 26 xul.dll mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:663 27 xul.dll mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) layout/base/nsRefreshDriver.cpp:583 28 xul.dll mozilla::detail::RunnableMethodImpl<void ( mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp), 1, 0, mozilla::TimeStamp>::Run() obj-firefox/dist/include/nsThreadUtils.h:810 29 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1216 30 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:361 31 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:124 32 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:225 33 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205 34 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp:156 35 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp:262 36 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:283 37 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:4472 38 xul.dll XREMain::XRE_main(int, char** const, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp:4605 39 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:4696 40 firefox.exe do_main browser/app/nsBrowserApp.cpp:282 41 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:115 42 firefox.exe __scrt_common_main_seh f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253 43 kernel32.dll BaseThreadInitThunk 44 ntdll.dll __RtlUserThreadStart 45 ntdll.dll _RtlUserThreadStart this signature is present since firefox 50 (bug 1284803?) - it was visibly rising in volume during the 52 beta cycle though.
Whiteboard: [gfx-noted]
Is the spike gone?
Flags: needinfo?(madperson)
no, the signature is still around in the latest 52 beta versions: http://bit.ly/2mcDUNE would you have expected them to go away by some other change?
Flags: needinfo?(madperson)
Right, I was more wondering if that huge spike went back down, or if the spike is coming from beta alone, or across all versions. To understand if we're looking for something in the environment, something beta specific, or a patch that landed everywhere.
the graphs for users of the bugzilla socorro lense addon might be misleading in this case (and including crashes from bug 1338771). this how the crash volume for just the [@ ARGBSetRow_X86] signature developed: http://bit.ly/2mxAINp
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
Too late for a fix for 53. Looks like this is mainly a problem on XP, in 52ESR, with around 75 crashes per day starting in early March 2017. That is not very high volume. But since it is marked with the high exploitability tag a lot of the time, I'm marking this security-sensitive and kicking it back to Milan.
Group: gfx-core-security
status-firefox53: affected → wontfix
status-firefox54: ? → affected
status-firefox55: --- → ?
status-firefox-esr52: --- → affected
tracking-firefox-esr52: --- → ?
Flags: needinfo?(milan)
Sotaro, could you take a look? Even if this ends up being XP only, it could be a good candidate for ESR52.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(milan) → needinfo?(sotaro.ikeda.g)
I looked in to the following functions of ESR52, but I did not find a problem in source code.. - ARGBSetRow_X86() - ARGBRect() - InitBuffer() - MemoryTextureData::Create() - ShmemTextureData::Create()
Flags: needinfo?(sotaro.ikeda.g)
From comment 9, it seems that allocated buffer might not be valid by some reasons when the crash happened. I wonder if jemalloc might be related. it is updated by Bug 1322027 and Bug 1343432.
There are crashes of MemoryTextureData::Create() and ShmemTextureData::Create(), they might be caused by different reason. If the caused by incorrect buffer allocation.
On windows ARGBSetRow_C() is used on 64bit build and ARGBSetRow_X86() is used on 32bit build.
(In reply to Sotaro Ikeda [:sotaro] from comment #10) > I wonder if jemalloc might be related. it is updated by Bug 1322027 and Bug 1343432. We don't ship with jemalloc 4 -- see bug 762449 This seems to be a dupe of bug 1338771 except this is the Windows signature and on linux it's [@ libyuv::ARGBSetRow_X86 ] instead.
Keywords: csectype-bounds, sec-high
See Also: → 1338771
Whiteboard: [gfx-noted] → [gfx-noted] dupe of 1338771?
Too late for 54. Bug 1338771 has a couple hits on 55, so I'm going to provisionally call this affected as well.
status-firefox54: affected → wontfix
status-firefox55: ? → affected
Sotaro, what's the status of this bug? Are you still working on this?
Flags: needinfo?(sotaro.ikeda.g)
Sorry, I did not working on it recently since, the bug seemed to be caused by shared memory allocation failure by OS. It looks similar to bug 1338771. I rechecked crash reports. From it, the crash happened only on 32bit build Firefox on Windows7/Window7 SP1. All crash reports had the following - OS: Windows 7 - OS Version: 6.1.7601 Service Pack 1 / 6.1.7600 - Build Architecture: x86
Flags: needinfo?(sotaro.ikeda.g)
Assignee: sotaro.ikeda.g → nobody
:jrmuizel, can you advice if there is a way to address the problem? Thanks!
Flags: needinfo?(jmuizelaar)
Hi Milan: I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them. Thanks! Wennie
Assignee: nobody → milan
Flags: needinfo?(jmuizelaar)
Jeff, can we use the patch from bug 1245239, together with the suggestion in bug 1245239 comment 6 to crash instead of running into the security issue?
Assignee: milan → jmuizelaar
Flags: needinfo?(jmuizelaar)
See Also: → 1414557
Flags: needinfo?(milan)
Bug 1245239 will only impact Linux. It seems like there must be something else going on here.
See Also: → 1457113
Flags: needinfo?(jmuizelaar)
Keywords: stalled
Blocks: 1631680

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(milaninbugzilla) → needinfo?(bhood)

Philip, this report years old now. Could you please re-check behavior with the current release of Firefox and update on whether it remains?

Flags: needinfo?(bhood) → needinfo?(madperson)

hi, i have filed this report not because i was affected myself but based on public crash stats for firefox, which showed that this signature was visibly spiking in volume in firefox 52 all those years ago.

revisiting the crash data now, it seems that this crash has mostly shifted to linux builds (bug 1631680) in the meantime, but has also only stuck with firefox 78esr.
current esr and release builds seem mostly unaffected, so i assume there isn't much value in keeping this bug report open.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(madperson)
Resolution: --- → WORKSFORME

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled
Group: gfx-core-security
You need to log in before you can comment on or make changes to this bug.