1345004 - SEGV at unknown address in [@ mozilla::net::nsBinHexDecoder::ProcessNextState]

Status: RESOLVED DUPLICATE of bug 1342661

(Core :: Networking, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: test_case.html

==8792==ERROR: AddressSanitizer: SEGV on unknown address 0x7f6a180edaa0 (pc 0x7f6a0d13b319 bp 0x7ffe7bf333e0 sp 0x7ffe7bf332e0 T0)
    #0 0x7f6a0d13b318 in mozilla::net::nsBinHexDecoder::ProcessNextState(nsIRequest*, nsISupports*) /home/worker/workspace/build/src/netwerk/streamconv/converters/nsBinHexDecoder.cpp:178:36
    #1 0x7f6a0d13a5ad in mozilla::net::nsBinHexDecoder::ProcessNextChunk(nsIRequest*, nsISupports*, unsigned int) /home/worker/workspace/build/src/netwerk/streamconv/converters/nsBinHexDecoder.cpp:401:13
    #2 0x7f6a0d139de2 in mozilla::net::nsBinHexDecoder::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) /home/worker/workspace/build/src/netwerk/streamconv/converters/nsBinHexDecoder.cpp:141:7
    #3 0x7f6a0cb76302 in nsBaseChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) /home/worker/workspace/build/src/netwerk/base/nsBaseChannel.cpp:856:17
    #4 0x7f6a0cbc0f56 in nsInputStreamPump::OnStateTransfer() /home/worker/workspace/build/src/netwerk/base/nsInputStreamPump.cpp:601:22
    #5 0x7f6a0cbbfb4a in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) /home/worker/workspace/build/src/netwerk/base/nsInputStreamPump.cpp:429:25
    #6 0x7f6a0c9acbad in nsInputStreamReadyEvent::Run() /home/worker/workspace/build/src/xpcom/io/nsStreamUtils.cpp:96:9
    #7 0x7f6a0ca0e9a2 in nsThread::ProcessNextEvent(bool, bool*) /home/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1264:7
    #8 0x7f6a0ca0b250 in NS_ProcessNextEvent(nsIThread*, bool) /home/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:389:10
    #9 0x7f6a0d80fe5f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/worker/workspace/build/src/ipc/glue/MessagePump.cpp:96:21
    #10 0x7f6a0d7811f8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #11 0x7f6a0d7811f8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #12 0x7f6a0d7811f8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #13 0x7f6a12be839f in nsBaseAppShell::Run() /home/worker/workspace/build/src/widget/nsBaseAppShell.cpp:156:3
    #14 0x7f6a16279911 in nsAppStartup::Run() /home/worker/workspace/build/src/toolkit/components/startup/nsAppStartup.cpp:283:19
    #15 0x7f6a1644569c in XREMain::XRE_mainRun() /home/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4476:10
    #16 0x7f6a16447198 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4654:8
    #17 0x7f6a1644845c in XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/worker/workspace/build/src/toolkit/xre/nsAppRunner.cpp:4745:16
    #18 0x4dffaf in do_main /home/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:236:10
    #19 0x4dffaf in main /home/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:307
    #20 0x7f6a27e3582f in __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:291
    #21 0x41c3d8 in _start (/home/user/workspace/browsers/firefox_cnt/firefox+0x41c3d8)

Comment 1

[Ryan VanderMeulen [:RyanVM]]

INFO: Last good revision: 33840f0669e79db9fe0be87b71a2c04a2bb25046
INFO: First bad revision: d0337c1582a148c5e7ebc441010074256edb8839
INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33840f0669e79db9fe0be87b71a2c04a2bb25046&tochange=d0337c1582a148c5e7ebc441010074256edb8839

INFO: Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1276625

"Firefox can’t find the file at /C:/Users/Ryan/repos/next_test"

Comment 2

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #1)
> "Firefox can’t find the file at /C:/Users/Ryan/repos/next_test"

Sorry, that was a stray comment. That's the pre-crash behavior in older builds.

Comment 3

[Daniel Stenberg [:bagder]]

Looks like a dupe of bug 1342661 to me based on the stack trace. I don't see how the fix to bug 1276625 (https://hg.mozilla.org/mozilla-central/rev/d0337c1582a1) introduced this though.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Confirmed locally that the patch from bug 1342661 fixes the crash and restores us to the prior "Firefox can’t find the file at /C:/Users/Ryan/repos/next_test" behavior that was there before bug 1276625 landed.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

I have it in rr on linux.  Trivial repro.

Crashing on 178	      mName.BeginWriting()[mCount] = c;

mName is:
(rr) p *this
$5 = {
  mData = 0x7fb464661748 <gNullChar> "", 
  mLength = 0, 
  mFlags = 1
}
This calls EnsureMutable(), which calls SetLength(0xFFFFFFFF, mozilla::fallible).
This goes to nsACString_internal::SetLength (this=0x7fb4358ec798, aLength=0, aFallible=...) (since mLength = 0)

So, it's trying to write data into an empty string (mName).

This traces back to mRlebuf being set to 0; it was 0xE4.  This matters because in ProcessNextState, in BINHEX_STATE_START, mRlebuf & 63 is used to set the length of mName (and thus it wouldn't be 0).

Likely this is a "bad" binhex encoding that isn't getting caught - mRelbuf isn't getting set in ProcessNextChunk before we call ProcessNextState.  (we search ~470 chars into the buffer for the "start" (':') char)

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

ASAN with this testcase might catch it directly; didn't try

Comment 8

[Marcia Knous [:marcia]]

Updating tracking flags so this falls off the release health dashboard.