1337814 - Hit MOZ_CRASH(element wasn't found in this list!) at LinkedList.h:635

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: bughunter stack

Hit MOZ_CRASH(element wasn't found in this list!) at c:\builds\moz2_slave\m-cen-w32-d-000000000000000000\build\src\obj-firefox\dist\include\mozilla/LinkedList.h:635

Found via bughunter and reproduced on latest m-c windows tinderbox trunk debug build.

Seems this is a debug only crash.

Steps to reproduce:
-> Load https://www.linkedin.com/company-beta/1680?pathWildcard=1680
--> Crash on load 

Filing as sec bug because we get asan heap-use-after-free that seems related for youtube urls

Comment 1

[Carsten Book [:Tomcat]]

nathan, do you know who could take a look at this crash ?

Comment 2

[Carsten Book [:Tomcat]]

[Tracking Requested - why for this release]:

so far only trunk reports on bughunter for windows and linux so far, so seems some kind of trunk regression

Comment 3

[Nathan Froyd [:froydnj]]

Andreas, perhaps, since this involves idle requests/idle callbacks.

Comment 4

[Carsten Book [:Tomcat]]

Attachment: asan report

Comment 5

[Andreas Farre [:farre]]

Added :smaug. Looking at it now.

Comment 6

[Andrew McCreight [:mccr8]]

This sounds very similar to bug 1315232, in terms of the test cases.

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

I hit this almost instantly when logging into LinkedIn and scrolling/loading the contact list on "My Network" [1].

[1] https://www.linkedin.com/mynetwork/

Comment 8

[Bob Clary [:bc] (inactive)]

fwiw, we first saw the MOZ_CRASH and ASAN heap-use-after-free on 2017-01-29.

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to Tim Taubert [:ttaubert] from comment #7)
> I hit this almost instantly when logging into LinkedIn and scrolling/loading
> the contact list on "My Network" [1].

Can you try that in an ASan build and attach the stack to this bug, please (if you have one handy)? Thanks.

Comment 12

[Andreas Farre [:farre]]

Attachment: 0001-Bug-1337814-Add-test-for-cancelling-currently-execut.patch

Comment 13

[Andreas Farre [:farre]]

Attachment: 0002-Bug-1337814-Remove-rIC-callback-from-pending-callbac.patch

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Andrew McCreight [:mccr8] from comment #10)
> Can you try that in an ASan build and attach the stack to this bug, please
> (if you have one handy)? Thanks.

So I downloaded the opt and debug versions of the m-c ASan builds. I can easily reproduce but the opt build doesn't give me a useful stack trace, and the debug build hits MOZ_CRASH() :/

Comment 15

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

Comment on attachment 8834992 [details] [diff] [review]
0002-Bug-1337814-Remove-rIC-callback-from-pending-callbac.patch

> {
>   AssertIsOnMainThread();
>   RefPtr<IdleRequest> request(aRequest);
>-  nsresult result = request->IdleRun(AsInner(), aDeadline, aDidTimeout);
>   RemoveIdleCallback(request);
>+  nsresult result = request->IdleRun(AsInner(), aDeadline, aDidTimeout);
>+
>   return result;

Why not just 
return request->IdleRun(AsInner(), aDeadline, aDidTimeout);

Comment 16

[Andreas Farre [:farre]]

Attachment: 0002-Bug-1337814-Remove-rIC-callback-from-pending-callbac.patch

Comment 17

[Andreas Farre [:farre]]

Attachment: 0002-Bug-1337814-Remove-rIC-callback-from-pending-callbac.patch

Tweaked commit message.

Comment 18

[Marcia Knous [:marcia]]

Tracking 54+ for this sec critical issue.

Comment 19

[Andreas Farre [:farre]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bf910e9138d0
Bug 1337814 - Add test for cancelling currently executing rIC callback. r=smaug

https://hg.mozilla.org/integration/mozilla-inbound/rev/7ec7752867ac
Bug 1337814 - Remove rIC callback from pending callbacks before running it. r=smaug

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/bf910e9138d0
https://hg.mozilla.org/mozilla-central/rev/7ec7752867ac

Comment 21

[Carsten Book [:Tomcat]]

are we sure this is just 54 ? in bug 1337707 calixte mentioned 51 and 52 as crash signatures. 

Will also do more testing now

Comment 22

[Andrew McCreight [:mccr8]]

(In reply to Carsten Book [:Tomcat] from comment #21)
> are we sure this is just 54 ? in bug 1337707 calixte mentioned 51 and 52 as
> crash signatures. 

It won't hurt to check older branches, but these signatures are mostly just generic memory corruption signatures, so it isn't surprising to see them on lower volume elsewhere.