1587534 - ASAN failure: ERROR: AddressSanitizer: requested allocation size 0x7ffaf606e0f0 (0x7ffaf606f0f0 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=270243806&repo=try&lineNumber=11154

Call stack:

#0 0x7ffb2aed4610 in malloc Z:\task_1569588313\fetches\llvm-project\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cc:69
#1 0x7ffaf562a14a in nsIncrementalStreamLoader::OnStartRequest z:\build\build\src\netwerk\base\nsIncrementalStreamLoader.cpp:66
#2 0x7ffaf5fc29d2 in mozilla::net::HttpChannelChild::DoOnStartRequest z:\build\build\src\netwerk\protocol\http\HttpChannelChild.cpp:682
#3 0x7ffaf5fcdca7 in mozilla::net::HttpChannelChild::OnStartRequest z:\build\build\src\netwerk\protocol\http\HttpChannelChild.cpp:607
#4 0x7ffaf607851f in mozilla::net::StartRequestEvent::Run z:\build\build\src\netwerk\protocol\http\HttpChannelChild.cpp:426
#5 0x7ffaf5e770d8 in mozilla::net::ChannelEventQueue::RunOrEnqueue z:\build\build\src\obj-firefox\dist\include\mozilla\net\ChannelEventQueue.h:210
#6 0x7ffaf5fcbe95 in mozilla::net::HttpChannelChild::RecvOnStartRequest z:\build\build\src\netwerk\protocol\http\HttpChannelChild.cpp:488
#7 0x7ffaf6a4bdf4 in mozilla::net::PHttpChannelChild::OnMessageReceived z:\build\build\src\obj-firefox\ipc\ipdl\PHttpChannelChild.cpp:833
#8 0x7ffaf67eccbf in mozilla::dom::PContentChild::OnMessageReceived z:\build\build\src\obj-firefox\ipc\ipdl\PContentChild.cpp:7879
#9 0x7ffaf65bff5a in mozilla::ipc::MessageChannel::DispatchAsyncMessage z:\build\build\src\ipc\glue\MessageChannel.cpp:2185
#10 0x7ffaf65bbafd in mozilla::ipc::MessageChannel::DispatchMessage z:\build\build\src\ipc\glue\MessageChannel.cpp:2109
#11 0x7ffaf65bdc44 in mozilla::ipc::MessageChannel::RunMessage z:\build\build\src\ipc\glue\MessageChannel.cpp:1954
#12 0x7ffaf65be2f5 in mozilla::ipc::MessageChannel::MessageTask::Run z:\build\build\src\ipc\glue\MessageChannel.cpp:1985
#13 0x7ffaf53359a5 in mozilla::SchedulerGroup::Runnable::Run z:\build\build\src\xpcom\threads\SchedulerGroup.cpp:295
#14 0x7ffaf53637e9 in nsThread::ProcessNextEvent z:\build\build\src\xpcom\threads\nsThread.cpp:1225
#15 0x7ffaf536cd48 in NS_ProcessNextEvent z:\build\build\src\xpcom\threads\nsThreadUtils.cpp:486
#16 0x7ffaf65c814f in mozilla::ipc::MessagePump::Run z:\build\build\src\ipc\glue\MessagePump.cpp:88
#17 0x7ffaf65010ae in MessageLoop::RunHandler z:\build\build\src\ipc\chromium\src\base\message_loop.cc:308
#18 0x7ffaf6500e45 in MessageLoop::Run z:\build\build\src\ipc\chromium\src\base\message_loop.cc:290
#19 0x7ffaffeb63ea in nsBaseAppShell::Run z:\build\build\src\widget\nsBaseAppShell.cpp:137
#20 0x7ffb0004dc18 in nsAppShell::Run z:\build\build\src\widget\windows\nsAppShell.cpp:406
#21 0x7ffb041bf1ed in XRE_RunAppShell z:\build\build\src\toolkit\xre\nsEmbedFunctions.cpp:934
#22 0x7ffaf65010ae in MessageLoop::RunHandler z:\build\build\src\ipc\chromium\src\base\message_loop.cc:308
#23 0x7ffaf6500e45 in MessageLoop::Run z:\build\build\src\ipc\chromium\src\base\message_loop.cc:290
#24 0x7ffb041be3d5 in XRE_InitChildProcess z:\build\build\src\toolkit\xre\nsEmbedFunctions.cpp:769
#25 0x7ff60c2020f4 in NS_internal_main z:\build\build\src\browser\app\nsBrowserApp.cpp:273
#26 0x7ff60c2014f2 in wmain z:\build\build\src\toolkit\xre\nsWindowsWMain.cpp:131
#27 0x7ff60c2fc0d7 in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288
#28 0x7ffb433e3033 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180013033)
#29 0x7ffb43f31460 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180071460)

The scary part to me is that the allocation length looks a lot like a pointer to something on the stack.

Comment 1

[Michal Novotny [:michal]]

Attachment: Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

CacheEntry::GetAltDataSize() can throw an error if the size isn't known yet, i.e. when the output stream wasn't closed yet. nsHttpChannel::OpenCacheInputStream() doesn't check the return value and in case of failure uninitialized altDataSize is stored in mAltDataLength.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c67998c390c1
nsHttpChannel can return invalid content length for alternative data, r=valentin

Comment 3

[Michal Novotny [:michal]]

Comment on attachment 9112245 [details]
Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

Beta/Release Uplift Approval Request

• User impact if declined: It's hard to guess. nsIChannel.contentLength might be wrong and it depends on the consumer whether it handles the mismatch between contentLength information and actual data size. E.g. in nsIncrementalStreamLoader it can cause cancelling the channel at https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/base/nsIncrementalStreamLoader.cpp#62 or pre-allocating too big buffer at https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/base/nsIncrementalStreamLoader.cpp#66. But in the latter case the memory won't be committed and will be released so it's probably not critical.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's trivial change.
• String changes made/needed: none

Comment 4

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/c67998c390c1

Comment 5

[Pascal Chevrel:pascalc]

Comment on attachment 9112245 [details]
Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

We have built our last RC and the end-user impact does not seem worth having an extra RC over the week end and QA on Monday before shipping. I am keeping the uplift approval open in case we have a 71 dot release in December.

Comment 7

[Pascal Chevrel:pascalc]

Comment on attachment 9112245 [details]
Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

There is no clear end-user impact, we are half way to 72 and we have no dot release planned for 71, so let's let it ride the 72 train

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Hi Michal, would this be safe to uplift to esr68? We're occasionally seeing these failures there as well and the patch grafts cleanly as-landed.

Comment 9

[Michal Novotny [:michal]]

Yes, it's a trivial change and it should be safe to uplift.

Comment 10

[Michal Novotny [:michal]]

Comment on attachment 9112245 [details]
Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This bug causes failures in debug builds and unexpected memory allocations in release builds. The change is trivial enough to uplift to ESR.
• User impact if declined: It's hard to guess. nsIChannel.contentLength might be wrong and it depends on the consumer whether it handles the mismatch between contentLength information and actual data size. E.g. in nsIncrementalStreamLoader it can cause cancelling the channel at https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/base/nsIncrementalStreamLoader.cpp#62 or pre-allocating too big buffer at https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/netwerk/base/nsIncrementalStreamLoader.cpp#66. But in the latter case the memory won't be committed and will be released so it's probably not critical.
• Fix Landed on Version: 72
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's trivial change.
• String or UUID changes made by this patch: none

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9112245 [details]
Bug 1587534 - nsHttpChannel can return invalid content length for alternative data, r=valentin

Low-risk fix for an intermittent failure affecting ESR still. Approved for 68.4esr.

Comment 12

[Razvan Maries]

https://hg.mozilla.org/releases/mozilla-esr68/rev/f3d3cd51bc51

Comment 13

[Intermittent Failures Robot]

1 failures in 4582 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-esr68: 1

Platform breakdown:

• windows10-64: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1587534&startday=2019-12-16&endday=2019-12-22&tree=all