1254061 - Program terminated with signal SIGSEGV, Segmentation fault. ParseInt64 nsHttpResponseHead

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Paul Menzel]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36

Steps to reproduce:

Browsing Google Chromecast pages. If I remember correctly, it crashed while the page was loading.


Actual results:

Program terminated with signal SIGSEGV, Segmentation fault.


Expected results:

No crash.

Comment 1

[Paul Menzel]

A core dump file was saved of the crash.

Core was generated by `iceweasel'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb76fdc11 in __kernel_vsyscall ()
(gdb) bt
#0  0xb76fdc11 in __kernel_vsyscall ()
#1  0xb76c7bb6 in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0xb42b147d in nsProfileLock::FatalSignalHandler (signo=11, info=0xaecfc8fc, context=0xaecfc8fc) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/profile/dirserviceprovider/nsProfileLock.cpp:180
#3  0xb46fe795 in AsmJSFaultHandler (signum=11, info=0xaecfc9cc, context=0xaecfca4c) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/js/src/asmjs/AsmJSSignalHandlers.cpp:940
#4  <signal handler called>
#5  mozilla::net::nsHttp::ParseInt64 (input=0x859ffffd "", next=0xaecfcd7c, r=0xaecfcd80) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttp.cpp:290
#6  0xb2e140d2 in mozilla::net::nsHttpResponseHead::ParseHeaderLine (this=0x84f4f880, line=0x859fffe8 "content-length") at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpResponseHead.cpp:343
#7  0xb2e14b82 in mozilla::net::nsHttpTransaction::ParseLineSegment (this=0x7bdabcc0, 
    segment=0x820db089 "x-content-type-options: nosniff\n\ncache-control: public, max-age=300, s-maxage=300\r\np3p: CP=\"This is not a P3P policy! See https://de.wikipedia.org/wiki/Spezial:CentralAutoLogin/P3P for more info.\"\r\nco"..., len=32)
    at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1287
#8  0xb2e14d3f in mozilla::net::nsHttpTransaction::ParseHead (this=0x7bdabcc0, buf=<optimized out>, count=938, countRead=0xaecfce34) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1413
#9  0xb2e1634e in mozilla::net::nsHttpTransaction::ProcessData (this=0x7bdabcc0, buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"..., 
    count=938, countRead=0xaecfcf28) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1695
#10 0xb2e17f3c in mozilla::net::nsHttpTransaction::WritePipeSegment (stream=0x85368668, closure=0x7bdabcc0, 
    buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"..., offset=0, count=32768, countWritten=0xaecfcf28)
    at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:737
#11 0xb2caa49c in nsPipeOutputStream::WriteSegments (this=0x85368668, aReader=0xb2e17eb6 <mozilla::net::nsHttpTransaction::WritePipeSegment(nsIOutputStream*, void*, char*, unsigned int, unsigned int, unsigned int*)>, aClosure=0x7bdabcc0, aCount=32768, aWriteCount=0xaecfe038)
    at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/io/nsPipe3.cpp:1648
#12 0xb2e12c88 in mozilla::net::nsHttpTransaction::WriteSegments (this=0x7bdabcc0, writer=0x84fa8cc4, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:755
#13 0xb2dc7d9b in mozilla::net::SpdyStream31::WriteSegments (this=0x84fa8cc0, writer=0x7afe4410, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdyStream31.cpp:231
#14 0xb2de58f1 in mozilla::net::SpdySession31::WriteSegments (this=0x7afe4400, writer=0x3afc, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdySession31.cpp:2168
#15 0xb2e0c83a in mozilla::net::nsHttpConnection::OnSocketReadable (this=0x832fc5b0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:1736
#16 0xb2e0d195 in mozilla::net::nsHttpConnection::OnInputStreamReady (this=0x832fc5b0, in=0x7c7e0998) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:2046
#17 0xb2d1d5bf in nsSocketInputStream::OnSocketReady (this=0x7c7e0998, condition=NS_OK) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:283
#18 0xb2d265b6 in nsSocketTransport::OnSocketReady (this=0x7c7e08a0, fd=0x82644c40, outFlags=1) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:1833
#19 0xb2d33eb7 in nsSocketTransportService::DoPollIteration (this=0xb7163b80, wait=true) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:900
#20 0xb2d34073 in nsSocketTransportService::Run (this=0xb7163b80) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:732
#21 0xb2cb7936 in nsThread::ProcessNextEvent (this=0xb712c2e0, aMayWait=true, aResult=0xaecfe1fb) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/threads/nsThread.cpp:855
#22 0xb2cccde5 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=true) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/glue/nsThreadUtils.cpp:265
#23 0xb2e9f4c2 in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0xaf523bb0, aDelegate=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/glue/MessagePump.cpp:368
#24 0xb2e92c9a in MessageLoop::RunInternal (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:233
#25 0xb2e92de8 in RunHandler (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:226
#26 MessageLoop::Run (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:200
#27 0xb2cb9b64 in nsThread::ThreadFunc (aArg=0xb712c2e0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/threads/nsThread.cpp:356
#28 0xb7391c35 in _pt_root (arg=0xb71266c0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/nsprpub/pr/src/pthreads/ptthread.c:212
#29 0xb76bfefb in start_thread (arg=0xaecfeb40) at pthread_create.c:309
#30 0xb749cede in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Comment 2

[Paul Menzel]

I am using Debian GNU/Linux 8.3 (jessie) with Iceweasel 38.6.1esr-1~deb8u1.

Comment 3

[Paul Menzel]

In the Debian BTS [1] this issues is tracked in the report with ID 817029 [2].


[1] bug tracking system
[2] http://bugs.debian.org/817029

Comment 4

[Paul Menzel]

The full backtrace is below.

```
(gdb) backtrace full
#0  0xb76fdc11 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb76c7bb6 in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
        resultvar = <optimized out>
        resultvar = <optimized out>
        pid = <optimized out>
#2  0xb42b147d in nsProfileLock::FatalSignalHandler (signo=11, info=0xaecfc8fc, context=0xaecfc8fc) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/profile/dirserviceprovider/nsProfileLock.cpp:180
        unblock_sigs = {__val = {1024, 0 <repeats 31 times>}}
        oldact = 0x0
#3  0xb46fe795 in AsmJSFaultHandler (signum=11, info=0xaecfc9cc, context=0xaecfca4c) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/js/src/asmjs/AsmJSSignalHandlers.cpp:940
        context = 0xaecfca4c
        info = 0xaecfc9cc
        signum = 11
#4  <signal handler called>
No symbol table info available.
#5  mozilla::net::nsHttp::ParseInt64 (input=0x859ffffd "", next=0xaecfcd7c, r=0xaecfcd80) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttp.cpp:290
        start = 0x859ffff8 "15107"
#6  0xb2e140d2 in mozilla::net::nsHttpResponseHead::ParseHeaderLine (this=0x84f4f880, line=0x859fffe8 "content-length") at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpResponseHead.cpp:343
        len = 15107
        ignored = 0xb6e32238 "\214\\P\004"
        hdr = {_val = 0xb4d92ac1 "Content-Length"}
        val = 0x859ffff8 "15107"
        rv = NS_OK
#7  0xb2e14b82 in mozilla::net::nsHttpTransaction::ParseLineSegment (this=0x7bdabcc0, segment=0x820db089 "x-content-type-options: nosniff\n\ncache-control: public, max-age=300, s-maxage=300\r\np3p: CP=\"This is not a P3P policy! See https://de.wikipedia.org/wiki/Spezial:CentralAutoLogin/P3P for more info.\"\r\nco"..., len=32) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1287
        rv = 170
#8  0xb2e14d3f in mozilla::net::nsHttpTransaction::ParseHead (this=0x7bdabcc0, buf=<optimized out>, count=938, countRead=0xaecfce34) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1413
        rv = <optimized out>
        len = <optimized out>
#9  0xb2e1634e in mozilla::net::nsHttpTransaction::ProcessData (this=0x7bdabcc0, buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"..., count=938, countRead=0xaecfcf28) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1695
        localBytesConsumed = 170
        bytesConsumed = 0
#10 0xb2e17f3c in mozilla::net::nsHttpTransaction::WritePipeSegment (stream=0x85368668, closure=0x7bdabcc0, buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"..., offset=0, count=32768, countWritten=0xaecfcf28) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:737
        rv = <optimized out>
        stream = 0x85368668
        count = 32768
        countWritten = 0xaecfcf28
        buf = 0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"...
        closure = 0x7bdabcc0
        offset = 0
#11 0xb2caa49c in nsPipeOutputStream::WriteSegments (this=0x85368668, aReader=0xb2e17eb6 <mozilla::net::nsHttpTransaction::WritePipeSegment(nsIOutputStream*, void*, char*, unsigned int, unsigned int, unsigned int*)>, aClosure=0x7bdabcc0, aCount=32768, aWriteCount=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/io/nsPipe3.cpp:1648
        readCount = 0
        originalLen = 32768
        rv = <optimized out>
        segment = 0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"...
        segmentLen = 32768
#12 0xb2e12c88 in mozilla::net::nsHttpTransaction::WriteSegments (this=0x7bdabcc0, writer=0x84fa8cc4, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:755
        rv = <optimized out>
        countWritten = 0xaecfe038
        count = 32768
        writer = 0x84fa8cc4
        this = 0x7bdabcc0
#13 0xb2dc7d9b in mozilla::net::SpdyStream31::WriteSegments (this=0x84fa8cc0, writer=0x7afe4410, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdyStream31.cpp:231
        rv = 2932854144
#14 0xb2de58f1 in mozilla::net::SpdySession31::WriteSegments (this=0x7afe4400, writer=0x3afc, count=32768, countWritten=0xaecfe038) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdySession31.cpp:2168
        stream = 0x84fa8cc0
        pushConnectedStream = 0x84fa8cc0
        sControlFunctions = {0x0, 0xb2de4798 <mozilla::net::SpdySession31::HandleSynStream(mozilla::net::SpdySession31*)>, 0xb2de4cf0 <mozilla::net::SpdySession31::HandleSynReply(mozilla::net::SpdySession31*)>, 0xb2ddf5b0 <mozilla::net::SpdySession31::HandleRstStream(mozilla::net::SpdySession31*)>, 0xb2ddf172 <mozilla::net::SpdySession31::HandleSettings(mozilla::net::SpdySession31*)>, 0xb2dd35ce <mozilla::net::SpdySession31::HandleNoop(mozilla::net::SpdySession31*)>, 0xb2dd394e <mozilla::net::SpdySession31::HandlePing(mozilla::net::SpdySession31*)>, 0xb2ddf3bc <mozilla::net::SpdySession31::HandleGoAway(mozilla::net::SpdySession31*)>, 0xb2de4fb6 <mozilla::net::SpdySession31::HandleHeaders(mozilla::net::SpdySession31*)>, 0xb2ddf72c <mozilla::net::SpdySession31::HandleWindowUpdate(mozilla::net::SpdySession31*)>, 0xb2dd3610 <mozilla::net::SpdySession31::HandleCredential(mozilla::net::SpdySession31*)>}
#15 0xb2e0c83a in mozilla::net::nsHttpConnection::OnSocketReadable (this=0x832fc5b0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:1736
        k400ms = 400
        n = 0
#16 0xb2e0d195 in mozilla::net::nsHttpConnection::OnInputStreamReady (this=0x832fc5b0, in=0x7c7e0998) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:2046
        rv = <optimized out>
#17 0xb2d1d5bf in nsSocketInputStream::OnSocketReady (this=0x7c7e0998, condition=NS_OK) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:283
        callback = {<nsCOMPtr_base> = {mRawPtr = 0x832fc5b8}, <No data fields>}
#18 0xb2d265b6 in nsSocketTransport::OnSocketReady (this=0x7c7e08a0, fd=0x82644c40, outFlags=1) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:1833
No locals.
#19 0xb2d33eb7 in nsSocketTransportService::DoPollIteration (this=0xb7163b80, wait=true) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:900
        desc = @0x0: <error reading variable>
        s = @0xaecfcd80: {mFD = 0x3b03, mHandler = 0x0, mElapsedTime = 48432}
        pollInterval = 0
#20 0xb2d34073 in nsSocketTransportService::Run (this=0xb7163b80) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:732
        pendingEvents = false
        goingOffline = 252
        thread = 0xb712c2e0
        threadInt = {<nsCOMPtr_base> = {mRawPtr = 0xb712c2e0}, <No data fields>}
#21 0xb2cb7936 in nsThread::ProcessNextEvent (this=0xb712c2e0, aMayWait=true, aResult=0xaecfe1fb) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/threads/nsThread.cpp:855
        event = {<nsCOMPtr_base> = {mRawPtr = 0xb7163b8c}, <No data fields>}
        reallyWait = <optimized out>
        notifyMainThreadObserver = <optimized out>
        obs = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
        rv = NS_OK
#22 0xb2cccde5 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=true) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/glue/nsThreadUtils.cpp:265
        val = true
#23 0xb2e9f4c2 in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0xaf523bb0, aDelegate=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/glue/MessagePump.cpp:368
        didWork = <optimized out>
#24 0xb2e92c9a in MessageLoop::RunInternal (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:233
No locals.
#25 0xb2e92de8 in RunHandler (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:226
No locals.
#26 MessageLoop::Run (this=0xb7171b40) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/ipc/chromium/src/base/message_loop.cc:200
        save_state = {<MessageLoop::RunState> = {run_depth = 1, quit_received = false}, loop_ = 0xb7171b40, previous_state_ = 0x0}
#27 0xb2cb9b64 in nsThread::ThreadFunc (aArg=0xb712c2e0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/threads/nsThread.cpp:356
        event = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
#28 0xb7391c35 in _pt_root (arg=0xb71266c0) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/nsprpub/pr/src/pthreads/ptthread.c:212
        rv = -1362113152
        tid = 10894
#29 0xb76bfefb in start_thread (arg=0xaecfeb40) at pthread_create.c:309
        __res = <optimized out>
        pd = 0xaecfeb40
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1217585152, -1362105536, 4001536, -1362107352, 1981614525, 1042708878}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#30 0xb749cede in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
No locals.
```

Comment 5

[ovidiu boca[:Ovidiu]]

Hi, 
Every time when you have a crash this is registred in about:crashes. After you have a crash please write in url bar "about:crashes" and under Submitted Crash Reports you will see Report ID. Please paste the report id.

Comment 6

[Paul Menzel]

Unfortunately, trying to access that page in Iceweasel 38, Iceweasel 44, Firfeox 45 in Debian, I get the message, that there is no such page.

Comment 7

[ovidiu boca[:Ovidiu]]

Maybe this link will help you, please take a look: https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent-and-get-help

Comment 8

[Paul Menzel]

As written, that is not possible right now in Debian GNU/Linux. And it’s also not needed as far as I can see. The core dump file was stored and I pasted the backtrace. Everything is there. If something is missing, `about:crashes` would show, which I have not provided yet, please tell me.

Comment 9

[ovidiu boca[:Ovidiu]]

Paul, 
  please give us some more information about this issue, maybe you can give us a link, the exact steps, this it happens all the time?

  Please download the Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

  We need more details about this issue to be able to choose the right component.

Comment 10

[:Gijs (he/him)]

The stacks look like a crash in netwerk, so I'm moving this and pinging :mcmanus, who can hopefully help with fixing/triaging this.

Paul, can you reproduce this on something more recent than the soon-to-be-EOL'd 38 ESR branch?

Comment 11

[Patrick McManus [:mcmanus]]

thanks. this is interesting - I wasn't aware of this stack and its actually a fairly active crash for android in particular on current versions

https://crash-stats.mozilla.com/search/?signature=~ParseInt64&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

This stack is: http://hg.mozilla.org/releases/mozilla-esr38/file/tip/netwerk/protocol/http/nsHttp.cpp#l290 .. and involves spdy

but looking at crash stats I see the same thing for h2 and h1 as well - so I don't think the http version matters

https://crash-stats.mozilla.com/report/index/b9dc7b81-efe8-4b11-956f-d1b262160308

https://crash-stats.mozilla.com/report/index/4b4e83a1-9a3d-44d4-953a-d1afa2160308

its not obvious what is going on there.. it could be related to bug 1247982, which valentin is looking at - so let's start there.

Comment 12

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

comment 4 is quite useful in figuring out what's going on.
As far as I can tell, the crash occurs in ParseInt64 while we are iterating through the characters.
The only way this would happen is if the underlying buffer [1] was freed by another thread.
I've looked through the stack frames, and none of the calls seem to AddRef the nsHttpTransaction, so unless I'm missing something this is probably the cause.

Patrick, does this make sense?

[1] http://hg.mozilla.org/releases/mozilla-release/annotate/5038ce33365b/netwerk/protocol/http/nsHttpTransaction.cpp#l1391

Comment 13

[Patrick McManus [:mcmanus]]

so SpdyStream31 and Http2Stream are both holding a reference to the nsAHttpTransaction with a RefPtr (that is the mTransaction->WriteSegments call on the stack).. nsHttpPipeline also keeps a ref to the transaction though its done manually there (one of the crash stats reports was on fennec so it was using pipelines.).. and in plain h1 (which I don't have a sample of handy) the ref is held as a member of the nsHttpConnection object which is on the stack..

Comment 14

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

I hadn't noticed that the callback was an nsHttpConnection.
Still, I can't find a better explanation for this issue than the transaction's buffer being freed.

Comment 15

[Patrick McManus [:mcmanus]]

unfortunately I think this might be a simpler, and therefore less widely applicable, bug.. its parsing the content length and crashes.

#5  mozilla::net::nsHttp::ParseInt64 (input=0x859ffffd "", next=0xaecfcd7c, r=0xaecfcd80) at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttp.cpp:290
        start = 0x859ffff8 "15107"

it crashes deref'ing *input.. which is points 5 chars past "start" (which is on the stack and was the value of input when the function started). and the content length is 5 characters long "15107". so it looks like it wandered off the end of the buffer.

but the buffer is supposed to be a null terminated string.. I bet there is a bug in that somewhere.

Comment 16

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

nsHttpTransaction::ParseLineSegment -> mLineBuf.Truncate(mLineBuf.Length() - 1); -> nsTSubstring_CharT::SetCapacity
SetCapacity always adds a null terminator, and from the gdb output the string also appears to be null terminated. So that doesn't seem to be the case.
Moreover, nsHttpHeaderArray::ParseHeaderLine which is called from nsHttpResponseHead::ParseHeaderLine before calling to ParseInt64 also writes a null terminator there, and the write works. I don't see how we could wander off the end of the buffer.

Comment 17

[Paul Menzel]

Hi, everyone! Thank you very much for looking into this issue. Unfortunately (or luckily) I hit this crash only once.

Please tell me, if I can provide more information, and I’ll see what I can do.

Comment 18

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

The only other way would be if someone calls nsHttpTransaction::Close() on the wrong thread, which calls to mLineBuf.Truncate();
MOZ_ASSERT(PR_GetCurrentThread() == gSocketThread); wouldn't catch it on release builds.
I've looked at the callers, and none of them stand out as an obvious problem.

Comment 19

[Patrick McManus [:mcmanus]]

I agree.. and yet that's exactly where the pointer is. doesn't seem like conincidence.

This ONLY impacts linux x86, including android but on that only x86. Which is weird.

Comment 20

[Patrick McManus [:mcmanus]]

I would be surprised if something was calling close from main thread.. that would be a disaster in a lot of other ways too and we would certainly see crashes in places other than linux x86

Comment 21

[Patrick McManus [:mcmanus]]

here is one that is parsing a cache entry - there isn't even a nsHttpTransaction on the stack! So I think we can stop worrying about that theory..

https://crash-stats.mozilla.com/report/index/03c8d77d-890b-4942-8125-a37612160312

Comment 22

[Patrick McManus [:mcmanus]]

this is a totally different one

https://crash-stats.mozilla.com/report/index/24aa035c-5985-4953-a42b-514dd2160314

Comment 23

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

I just noticed that all of the crashes have an ebp which ends in ffffd and all occur when crossing the page boundary.
You're probably right, that we go outside the buffer, but I have no idea why. I'll have to look at the disassembly to make any sense why this happens. It could be some weird undefined behaviour and depend on the compiler.

Comment 24

[Patrick McManus [:mcmanus]]

I wonder if there isn't some kind of implicit cast in there promoting something to 32 bits.

https://bugzilla.mozilla.org/show_bug.cgi?id=959093 points out that the function doesn't do overflow right anyhow, and it has that weird shadowing of "next" as a variable name.. and the second arg is pretty much only used in one place in the code base (and could be replaced with a strstr(',')..

so I'm going to suggest you just rewrite the function with strtoll() (or similar) and we'll see what happens to crash stats.

Comment 25

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e1ce88baf7cc

Comment 26

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Attachment: MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus

* * *
[mq]: test

Review commit: https://reviewboard.mozilla.org/r/41109/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/41109/

Comment 27

[Patrick McManus [:mcmanus]]

Comment on attachment 8732339 [details]
MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus

https://reviewboard.mozilla.org/r/41109/#review37709

::: netwerk/protocol/http/nsHttp.cpp:302
(Diff revision 1)
>  {
> -    const char *start = input;
> -    *r = 0;
> -    while (*input >= '0' && *input <= '9') {
> -        int64_t next = 10 * (*r) + (*input - '0');
> -        if (next < *r) // overflow?
> +    MOZ_ASSERT(input);
> +    MOZ_ASSERT(r);
> +
> +    // Must start with a digit.
> +    if (*input < '0' || *input > '9') {

I think we don't want to do this *input < '0' bit (it might be related to the whole issue we are tickling) and its not required. Its ok if the new version allows leading whitespace)

you can check to see if nothing was found (as opposed to the string "0" being parsed) and return false via "If there were no digits at all, strtol() stores the original value of nptr in *endptr (and returns 0). "

::: netwerk/protocol/http/nsHttp.cpp:311
(Diff revision 1)
> +    char *end = nullptr;
> +    errno = 0; // Clear errno to make sure its value is set by strtoll
> +    int64_t value = strtoll(input, &end, /* base */ 10);
> +
> +    // Fail if the parsed number overflows.
> +    if (errno == ERANGE) {

if errno != 0.. and log it (EINVAL?)

Comment 28

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

(In reply to Patrick McManus [:mcmanus] from comment #27)
> Comment on attachment 8732339 [details]
> MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus
> 
> https://reviewboard.mozilla.org/r/41109/#review37709
> 
> ::: netwerk/protocol/http/nsHttp.cpp:302
> > +    // Must start with a digit.
> > +    if (*input < '0' || *input > '9') {
> 
> I think we don't want to do this *input < '0' bit (it might be related to
> the whole issue we are tickling) and its not required. Its ok if the new
> version allows leading whitespace)
> 
> you can check to see if nothing was found (as opposed to the string "0"
> being parsed) and return false via "If there were no digits at all, strtol()
> stores the original value of nptr in *endptr (and returns 0). "

I did this because strtoll allows parsing numbers that start with a + or a -.
Also, I think the method should fail for negative numbers.

Comment 29

[Paul Menzel]

Just another small note, you probably are already aware of. The crash happened on a 32-bit system.

Comment 30

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Comment on attachment 8732339 [details]
MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/41109/diff/1-2/

Comment 31

[Patrick McManus [:mcmanus]]

Comment on attachment 8732339 [details]
MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus

https://reviewboard.mozilla.org/r/41109/#review37923

Comment 32

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/74312d99d538

Comment 33

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for build bustage.

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/52c1e3e2fcfb

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=74312d99d538
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=24254080&repo=mozilla-inbound
1:01:26     INFO -  In file included from /builds/slave/m-in-and-api-15-00000000000000/build/src/obj-firefox/netwerk/protocol/http/Unified_cpp_protocol_http1.cpp:47:0:
11:01:26     INFO -  /builds/slave/m-in-and-api-15-00000000000000/build/src/netwerk/protocol/http/nsHttp.cpp: In static member function 'static bool mozilla::net::nsHttp::ParseInt64(const char*, const char**, int64_t*)':
11:01:26     INFO -  /builds/slave/m-in-and-api-15-00000000000000/build/src/netwerk/protocol/http/nsHttp.cpp:301:5: error: 'errno' was not declared in this scope
11:01:26     INFO -       errno = 0; // Clear errno to make sure its value is set by strtoll
11:01:26     INFO -       ^
11:01:26     INFO -  gmake[5]: *** [Unified_cpp_protocol_http1.o] Error 1
11:01:26     INFO -  gmake[5]: Leaving directory `/builds/slave/m-in-and-api-15-00000000000000/build/src/obj-firefox/netwerk/protocol/http'
11:01:26     INFO -  gmake[4]: *** [netwerk/protocol/http/target] Error 2
11:01:26     INFO -  gmake[4]: *** Waiting for unfinished jobs....

Comment 34

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b0b2c2c801c8

Comment 35

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c143be9df73e9f540d8d406590e934afb8dea3de
Bug 1254061 - Rewrite nsHttp::ParseInt64 using strtoll r=mcmanus

Comment 36

[Carsten Book [:Tomcat]]

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

Comment 37

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Attachment: Rewrite nsHttp::ParseInt64 using strtoll

Uploading landed patch in order to nominate for uplift

Comment 38

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Comment on attachment 8735821 [details] [diff] [review]
Rewrite nsHttp::ParseInt64 using strtoll

Approval Request Comment

[Feature/regressing bug #]:
Preexisting issue probably due to gcc optimizations and undefined behaviour. This only occurs on x86 linux - Desktop and Android.
The crashing assembly line is
> mov edi, dword ptr [ebp]
> where ebp = 808FFFFD 

[User impact if declined]:
Crashes on x86 Linux and Android when parsing a string located at a page boundary in memory. 7500 crashes in the past 28 days according to crash-stats.

[Describe test coverage new/current, TreeHerder]:
No unit tests for this method, but code calling it is adequately tested.

[Risks and why]: 
The risk of regressions is low. The method is explicitly rewritten in order to maintain the same logic, and avoid undefined behaviour. The library call should not have any of the issues the previous code did.

[String/UUID change made/needed]:
None.

Comment 39

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8735821 [details] [diff] [review]
Rewrite nsHttp::ParseInt64 using strtoll

(Potential) Crash fix, Aurora47+

Comment 40

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dcb34dd97794

Comment 41

[Liz Henry (:lizzard)]

Adding [@mozilla::net::nsHttp::ParseInt64] as the crash signature, if I'm wrong about that please correct that or let me know, thanks.

Comment 42

[Liz Henry (:lizzard)]

Marking 45+ as affected. Sylvestre this looks like a fairly high volume crash in fennec 45.0.1 right now. just fyi.

Comment 43

[Liz Henry (:lizzard)]

Comment on attachment 8735821 [details] [diff] [review]
Rewrite nsHttp::ParseInt64 using strtoll

Crash fix, 46 is affected, let's uplift for beta 8

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/91a15187d047

Comment 45

[Sylvestre Ledru [:Sylvestre]]

Ok, tracking in case we are planning to do something with it.

Comment 46

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

I just found a crash (just one) that occurred on beta after landing this, so it may be that we didn't completely fix it.
It doesn't make a lot of sense to me. Patrick, could you take a look and advise on how we should proceed?
https://crash-stats.mozilla.com/report/index/2aa3b0d5-64bf-4436-a399-d28972160413

Comment 47

[Patrick McManus [:mcmanus]]

I guess I would start by asking if that's the same..

its windows and EXCEPTION_ACCESS_VIOLATION_WRITE .. so that might mean something different, right? (I'm just going by memory, but weren't they only linux platform reads before?)

Comment 48

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Yeah, it seems to be a bit different. I worry that we just traded undefined behaviour on one compiler for another.