Closed Bug 783133 Opened 12 years ago Closed 11 years ago

"###!!! ABORT: OnInputReady after stop without linger: 'mLingeringCloseTimer', file /home/neil/comm/mozilla/netwerk/protocol/websocket/WebSocketChannel.cpp, line 2949"

Categories

(Core :: Networking: WebSockets, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: neil, Assigned: dbaron)

References

Details

(Keywords: crash)

Attachments

(4 files, 1 obsolete file)

I was browsing Stack Overflow at the time. Sorry I can't be more helpful. Stack backtrace (on the socket transport thread): #0 0x00007ffff60ea541 in mozalloc_abort (msg= 0x7fffe87fde50 "###!!! ABORT: OnInputReady after stop without linger: 'mLingeringCloseTimer', file /home/neil/comm/mozilla/netwerk/protocol/websocket/WebSocketChannel.cpp, line 2949") at /home/neil/comm/mozilla/memory/mozalloc/mozalloc_abort.cpp:23 #1 0x00007ffff3d5cad3 in Abort (aMsg= 0x7fffe87fde50 "###!!! ABORT: OnInputReady after stop without linger: 'mLingeringCloseTimer', file /home/neil/comm/mozilla/netwerk/protocol/websocket/WebSocketChannel.cpp, line 2949") at /home/neil/comm/mozilla/xpcom/base/nsDebugImpl.cpp:423 #2 0x00007ffff3d5ca01 in NS_DebugBreak_P (aSeverity=3, aStr= 0x7ffff49cc988 "OnInputReady after stop without linger", aExpr= 0x7ffff49cc96d "mLingeringCloseTimer", aFile= 0x7ffff49ca058 "/home/neil/comm/mozilla/netwerk/protocol/websocket/WebSocketChannel.cpp", aLine=2949) at /home/neil/comm/mozilla/xpcom/base/nsDebugImpl.cpp:380 #3 0x00007ffff2049b48 in mozilla::net::WebSocketChannel::OnInputStreamReady ( this=0x7fffc3777800, aStream=0x7fffc21ef3a8) at /home/neil/comm/mozilla/netwerk/protocol/websocket/WebSocketChannel.cpp:2948 #4 0x00007ffff3d2a8d5 in nsInputStreamReadyEvent::Run (this=0x7fffc37af6c0) at /home/neil/comm/mozilla/xpcom/io/nsStreamUtils.cpp:82 #5 0x00007ffff3d4cd48 in nsThread::ProcessNextEvent (this=0x7ffff7d6c8b0, ---Type <return> to continue, or q <return> to quit--- mayWait=true, result=0x7fffe87fec2f) at /home/neil/comm/mozilla/xpcom/threads/nsThread.cpp:624 #6 0x00007ffff3ce14d2 in NS_ProcessNextEvent_P (thread=0x7ffff7d6c8b0, mayWait=true) at /home/neil/objdir/mozilla/xpcom/build/nsThreadUtils.cpp:220 #7 0x00007ffff1f1749e in nsSocketTransportService::Run (this=0x7ffff7d3fe20) at /home/neil/comm/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:621 #8 0x00007ffff3d4cd48 in nsThread::ProcessNextEvent (this=0x7ffff7d6c8b0, mayWait=true, result=0x7fffe87fedef) at /home/neil/comm/mozilla/xpcom/threads/nsThread.cpp:624 #9 0x00007ffff3ce14d2 in NS_ProcessNextEvent_P (thread=0x7ffff7d6c8b0, mayWait=true) at /home/neil/objdir/mozilla/xpcom/build/nsThreadUtils.cpp:220 #10 0x00007ffff3d4bc3f in nsThread::ThreadFunc (arg=0x7ffff7d6c8b0) at /home/neil/comm/mozilla/xpcom/threads/nsThread.cpp:257 #11 0x00007ffff7ae697d in _pt_root (arg=0x7ffff7d5bae0) at /home/neil/comm/mozilla/nsprpub/pr/src/pthreads/ptthread.c:156 #12 0x00000033e2c07d14 in start_thread (arg=0x7fffe87ff700) at pthread_create.c:309 #13 0x00000033e28f197d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Severity: normal → major
Keywords: crash
OS: Windows XP → Linux
Hardware: x86 → x86_64
ABORT: OnInputReady after stop without linger: 'mLingeringCloseTimer' NS_DebugBreak mozilla::net::WebSocketChannel::OnInputStreamReady mozilla::net::RunOnThread::Run nsThread::ProcessNextEvent NS_ProcessNextEvent http://www.itv.com/sport/football/article/2013-02-04/tottenham-and-brazilian-midfielder-sandro-shows-off-his-rapping-skills/ Windows, Linux/Beta, Aurora, Nightly - not 5-10% reproducible on Windows anyway... fyi, automation showed this without a processable minidump... Other examples that are semi reproducible on Windows at least: http://beta.gface.com/warface http://mixlr.com/rek-joni/crowd http://mixlr.com/ph-radio-online/playlist http://beta.gface.com/ http://www.livestation.com/en/press-tv http://beta.gface.com/dim56460 http://komikgratisanonline.blogspot.com/
OS: Linux → All
Hardware: x86_64 → All
I've hit this abort twice in the past week during regular browsing with a debug build. The second time may have involved https://twitter.com/ .
Attached file gdb session from abort
I'd also note that after the abort on the socket thread, I got on the main thread: JavaScript error: https://d3dy5gmtp8yhk7.cloudfront.net/1.9/pusher.min.js, line 20: Error: bf9cd54c54eadc2cf783: Invalid transition [impermanentlyClosing to impermanentlyClosing] which seems like it might be related.
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
Comment on attachment 8358225 [details] [diff] [review] Weaken NS_ABORT_IF_FALSE to NS_ASSERTION since it fires somewhat regularly. Review of attachment 8358225 [details] [diff] [review]: ----------------------------------------------------------------- I apologize for not giving this the attention it deserved earlier.. the ABORT line should simply be removed. can you write that patch? The abort is detecting a race condition between the main thread setting the stop flag and the socket thread processing input.. it actually does the right thing here in the absence of the abort no matter which side of the race it falls on. So we can just remove it.
Attachment #8358225 - Flags: review?(mcmanus)
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Comment on attachment 8358518 [details] [diff] [review] Remove NS_ABORT_IF_FALSE that fires somewhat regularly, which happens in a case that is correctly handled. Review of attachment 8358518 [details] [diff] [review]: ----------------------------------------------------------------- thanks david
Attachment #8358518 - Flags: review?(mcmanus) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: