Closed
Bug 1254061
Opened 8 years ago
Closed 8 years ago
Program terminated with signal SIGSEGV, Segmentation fault. ParseInt64 nsHttpResponseHead
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla48
People
(Reporter: paulepanter, Assigned: valentin)
References
(Blocks 1 open bug)
Details
(Keywords: crash, Whiteboard: [necko-active])
Crash Data
Attachments
(2 files)
58 bytes,
text/x-review-board-request
|
mcmanus
:
review+
|
Details |
2.20 KB,
patch
|
ritu
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•8 years ago
|
||
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
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Linux
Hardware: Unspecified → x86
Reporter | ||
Comment 2•8 years ago
|
||
I am using Debian GNU/Linux 8.3 (jessie) with Iceweasel 38.6.1esr-1~deb8u1.
Reporter | ||
Comment 3•8 years ago
|
||
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
Reporter | ||
Comment 4•8 years ago
|
||
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•8 years ago
|
||
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.
Flags: needinfo?(paulepanter)
Reporter | ||
Comment 6•8 years ago
|
||
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.
Flags: needinfo?(paulepanter)
Comment 7•8 years ago
|
||
Maybe this link will help you, please take a look: https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent-and-get-help
Flags: needinfo?(paulepanter)
Reporter | ||
Comment 8•8 years ago
|
||
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.
Flags: needinfo?(paulepanter)
Comment 9•8 years ago
|
||
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.
Component: Untriaged → General
Flags: needinfo?(paulepanter)
Comment 10•8 years ago
|
||
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?
Component: General → Networking
Flags: needinfo?(mcmanus)
Product: Firefox → Core
Comment 11•8 years ago
|
||
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.
Assignee: nobody → valentin.gosu
Flags: needinfo?(mcmanus) → needinfo?(valentin.gosu)
Keywords: crash
Summary: Program terminated with signal SIGSEGV, Segmentation fault. → Program terminated with signal SIGSEGV, Segmentation fault. ParseInt64 nsHttpResponseHead
Whiteboard: [necko-active]
Assignee | ||
Comment 12•8 years ago
|
||
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
Flags: needinfo?(valentin.gosu) → needinfo?(mcmanus)
Comment 13•8 years ago
|
||
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..
Flags: needinfo?(mcmanus)
Assignee | ||
Comment 14•8 years ago
|
||
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•8 years ago
|
||
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.
Assignee | ||
Comment 16•8 years ago
|
||
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.
Reporter | ||
Comment 17•8 years ago
|
||
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.
Flags: needinfo?(paulepanter)
Assignee | ||
Comment 18•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
this is a totally different one https://crash-stats.mozilla.com/report/index/24aa035c-5985-4953-a42b-514dd2160314
Assignee | ||
Comment 23•8 years ago
|
||
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•8 years ago
|
||
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.
Assignee | ||
Comment 25•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e1ce88baf7cc
Assignee | ||
Comment 26•8 years ago
|
||
* * * [mq]: test Review commit: https://reviewboard.mozilla.org/r/41109/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/41109/
Attachment #8732339 -
Flags: review?(mcmanus)
Comment 27•8 years ago
|
||
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?)
Attachment #8732339 -
Flags: review?(mcmanus)
Assignee | ||
Comment 28•8 years ago
|
||
(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.
Reporter | ||
Comment 29•8 years ago
|
||
Just another small note, you probably are already aware of. The crash happened on a 32-bit system.
Assignee | ||
Comment 30•8 years ago
|
||
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/
Attachment #8732339 -
Flags: review?(mcmanus)
Comment 31•8 years ago
|
||
Comment on attachment 8732339 [details] MozReview Request: Bug 1254061 - Rewrite nsHttp::ParseInt64 r?mcmanus https://reviewboard.mozilla.org/r/41109/#review37923
Attachment #8732339 -
Flags: review?(mcmanus) → review+
Comment 33•8 years ago
|
||
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....
Flags: needinfo?(valentin.gosu)
Assignee | ||
Comment 34•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b0b2c2c801c8
Assignee | ||
Comment 35•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c143be9df73e9f540d8d406590e934afb8dea3de Bug 1254061 - Rewrite nsHttp::ParseInt64 using strtoll r=mcmanus
Comment 36•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c143be9df73e
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Assignee | ||
Comment 37•8 years ago
|
||
Uploading landed patch in order to nominate for uplift
Assignee | ||
Comment 38•8 years ago
|
||
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.
Flags: needinfo?(valentin.gosu)
Attachment #8735821 -
Flags: approval-mozilla-beta?
Attachment #8735821 -
Flags: approval-mozilla-aurora?
status-firefox47:
--- → affected
Comment on attachment 8735821 [details] [diff] [review] Rewrite nsHttp::ParseInt64 using strtoll (Potential) Crash fix, Aurora47+
Attachment #8735821 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 40•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/dcb34dd97794
Comment 41•8 years ago
|
||
Adding [@mozilla::net::nsHttp::ParseInt64] as the crash signature, if I'm wrong about that please correct that or let me know, thanks.
Crash Signature: [@mozilla::net::nsHttp::ParseInt64]
Comment 42•8 years ago
|
||
Marking 45+ as affected. Sylvestre this looks like a fairly high volume crash in fennec 45.0.1 right now. just fyi.
Comment 43•8 years ago
|
||
Comment on attachment 8735821 [details] [diff] [review] Rewrite nsHttp::ParseInt64 using strtoll Crash fix, 46 is affected, let's uplift for beta 8
Attachment #8735821 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 44•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/91a15187d047
Comment 45•8 years ago
|
||
Ok, tracking in case we are planning to do something with it.
tracking-firefox45:
--- → +
Flags: needinfo?(sledru)
Updated•8 years ago
|
Assignee | ||
Comment 46•8 years ago
|
||
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•8 years ago
|
||
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?)
Assignee | ||
Comment 48•8 years ago
|
||
Yeah, it seems to be a bit different. I worry that we just traded undefined behaviour on one compiler for another.
You need to log in
before you can comment on or make changes to this bug.
Description
•