1626318 - Crash in [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::basic_string<T>::_Reallocate_grow_by<T>]

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[[:philipp]]

This bug is for crash report bp-c9e9ec9a-0a45-408f-9a6f-ce4a70200331.

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:54
3 xul.dll std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Reallocate_grow_by<`lambda at z:\task_1585360193\build\src\vs2017_15.8.4\VC\include\xstring:2609:4', unsigned int, char> vs2017_15.8.4/VC/include/xstring:3932
4 xul.dll std::basic_string<char, std::char_traits<char>, std::allocator<char> >::append vs2017_15.8.4/VC/include/xstring:2608
5 xul.dll TouchDeviceNeedsPanGestureConversion widget/windows/nsWindow.cpp:6773
6 xul.dll nsWindow::ConvertTouchToPanGesture widget/windows/nsWindow.cpp:6814
7 xul.dll nsWindow::DispatchTouchOrPanGestureInput widget/windows/nsWindow.cpp:6861
8 xul.dll nsWindow::OnTouch widget/windows/nsWindow.cpp:6953
9 xul.dll nsWindow::ProcessMessage widget/windows/nsWindow.cpp:5984

this crash signature with a stack going through TouchDeviceNeedsPanGestureConversion is showing up in very low volume since firefox 70 - potentially related to bug 1511901.

the signature is covering other (different) issues as well, this crash-stats query should narrow it down.

a high number of crash reports is showing that accessibility services are on.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

The linked crash report is attempting an allocation of 1,992,234,371 bytes. Smells like a type mismatch or maybe we just need to clamp the value we get back from the windows API. P2 since it seems like an easily avoidable crash.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I believe this is where the OOM is coming from.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

After poking around and reading the docs on MSDN I think what might be happening is that the first call to GetRawInputDeviceInfoA is failing unexpectedly, and it leaves dataSize to uninitialized garbage. I can protect against that as well as the function erroneously returning a giant value.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1626318 - Protect against dataSize being absurdly large. r?botond

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9f33de91089e
Protect against dataSize being absurdly large. r=botond

Comment 6

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/9f33de91089e

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 9137566 [details]
Bug 1626318 - Protect against dataSize being absurdly large. r?botond

Beta/Release Uplift Approval Request

• User impact if declined: Crashes sometimes when using touchpad input on Windows
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: No known steps. Just use the touchpad a lot
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Adding some safety guards to avoid attempting giant allocation
• String changes made/needed: none

Comment 8

[Julien Cristau [:jcristau]]

Comment on attachment 9137566 [details]
Bug 1626318 - Protect against dataSize being absurdly large. r?botond

we're late in rc week and this isn't new, so I'll let it ride 76.