1417448 - Crash in _platform_memmove$VARIANT$Haswell | <name omitted> | nsPipeInputStream::ReadSegments

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Stuart Philp :sphilp]

This bug was filed from the Socorro interface and is
report bp-cee067a7-78e8-4628-aa10-75fca0171115.
=============================================================

Top 10 frames of crashing thread:

0 libsystem_platform.dylib _platform_memmove$VARIANT$Haswell 
1 XUL <name omitted> xpcom/io/nsStreamUtils.cpp:825
2 XUL nsPipeInputStream::ReadSegments xpcom/io/nsPipe3.cpp:1448
3 XUL  netwerk/base/nsNetUtil.cpp:1584
4 XUL mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:246
5 XUL nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:228
6 XUL non-virtual thunk to nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:156
7 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1037
8 XUL NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:513
9 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:334

=============================================================

Details: Nightly 59.0a1(2017-11-14) on OSX 10.13.1. This crash was on wake from sleep, I hadn't interacted with the browser just lifted my mbp's lid. Prior to putting my laptop to sleep, I had a video playing that was likely still downloading playback segments... Also had several other tabs open like gdocs, gmail, etc. Sleep was overnight, probably 10 hours or so.

Comment 1

[Gary Chen [:xeonchen]]

Dragana might know this more

Comment 2

[Dragana Damjanovic [:dragana]]

This looks related to bug 1415081.
The first crash in on 10th. Nov. Bug 1415081 landed on 10th. Nov. The are old crashes on Thunderbird, but they have a bit different crash stack and a different crash address.

baku, can you take a look? (I am not sure if you have only moved code around or not)

Thanks

Comment 3

[Andrea Marchesini [:baku]]

Attachment: check.patch

It's hard to understand what happens here. Checking the crash reports I can see that there are no threads using NS_ReadInputStreamTo{String,Buffer}. This means that probably the operation is already completed.
But if the operation is completed, why do we have a runnable dispatched?
Could it be that lock.Wait() fails?

I added the following checks:

1. lock.Wait() return value check.
2. BufferWriter::Run() does everything protected by lock
3. StealBuffer also needs to be protected, plus it set mBufferSize to 0.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Based on code, Wait() doesn't ever fail, at least doesn't return any error value.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8930054 [details] [diff] [review]
check.patch

So this is a guess fix?

Comment 6

[Andrea Marchesini [:baku]]

Yes it is.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2173819ac195
Better use of monitors in NS_ReadInputStreamToBuffer, r=smaug

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/2173819ac195

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Please request Beta approval on this when you get a chance.

Comment 10

[Andrea Marchesini [:baku]]

Comment on attachment 8930054 [details] [diff] [review]
check.patch

Approval Request Comment
[Feature/Bug causing the regression]: bug 1415081
[User impact if declined]: a crash can occur.
[Is this code covered by automated tests?]: no, race condition
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: the buffer access is protected by mutex and its correctly nullified when needed.
[String changes made/needed]: none

Comment 11

[Gerry Chang [:gchang]]

Comment on attachment 8930054 [details] [diff] [review]
check.patch

Fix a crash. Beta58+.

Comment 12

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

https://hg.mozilla.org/releases/mozilla-beta/rev/b4a737a2a3d7

Comment 13

[Marcia Knous [:marcia]]

Looks as if we are still hitting this crash on Mac nightly after the fix went in on 11-20: http://bit.ly/2ANRCOY

Comment 14

[[:philipp]]

should we reopen the bug or file a new one for the remaining crashes?

Comment 15

[Andrea Marchesini [:baku]]

file a new bug, thanks.