1366296 - Intermittent devtools/client/netmonitor/test/browser_net_filter-02.js | application crashed [@ 0xf2d3dab477][@ js::TypeSet::GetValueType(JS::Value const &)]

Status: RESOLVED INCOMPLETE

(Core :: JavaScript: GC, defect)

Description

[Treeherder Bug Filer]

Filed by: rvandermeulen [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=100409909&repo=mozilla-inbound

https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-debug/1495183493/mozilla-inbound_win8_64-debug_test-mochitest-devtools-chrome-8-bm111-tests1-windows-build1572.txt.gz

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Looks s-s to me (rax = 0xfffe4b4b4b4b4b4b). Philor pointed out bug 1366083 and bug 1366153 as well, which also have 4b4b4b4b on their stacks. Jon, any idea what might have caused this in the last couple days?

Comment 2

[Jon Coppeard (:jonco)]

I can't see a smoking gun in js/src in the last few days.

Comment 3

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: sec-high regression

It should be possible to bisect one of these on TreeHerder. Bug 1366083 is happening in a single test suite, for instance.

Comment 4

[Julien Cristau [:jcristau] (back April 22)]

tracking as new regression in 55

Comment 5

[Andrew McCreight [:mccr8]]

This is happening in the same test directory as bug 1366083, which suggests that they are the same underlying issue.

Comment 6

[Andrew McCreight [:mccr8]]

This looks like it is happening on 3 different platforms, Win32, Win64 and OSX.

Jon, could you maybe take a look? It seems odd that at devtools change that is JS-only might be causing this.

Comment 7

[Jon Coppeard (:jonco)]

Investigating.  This might be an interaction between incremental object finalization (bug 1352430) and bug 1189822.

Comment 8

[Andrew McCreight [:mccr8]]

FWIW, bug 1366083 seems like the most frequent variant.

Comment 9

[Jon Coppeard (:jonco)]

I added some assertions and pushed a try build which shows that it's possible to have DOM proxies with expandos but without a preserved wrapper.  This would produce crashes like these.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=52a3466149d1c7184cf932c1887a91365f004409&group_state=expanded&selectedJob=101699377

Comment 10

[Jon Coppeard (:jonco)]

I wasn't able to track this down.  

The failures in bug 1366083 and bug 1366153 have dropped to nothing in the last week, but I wouldn't be surprised if there was still a problem here.

The only suspicious thing I found was that during unlinking nsWrapperCache::ReleaseWrapper can be called more than once for a DOM node that has a JS proxy object and expandoAndGeneration (we rely on the wrapper being preserved to mark the expando object).  However I wasn't able to observe any calls to get the expando object in between.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Are you going to keep investigating?  I will mark this fix-optional for 55, for now, since nothing seems immediately actionable.

Comment 12

[Nathan Froyd [:froydnj]]

We have some similar-ish looking crashes in crash stats:

https://crash-stats.mozilla.com/signature/?signature=js%3A%3ATypeSet%3A%3AGetValueType&date=%3E%3D2017-06-21T21%3A47%3A00.000Z&date=%3C2017-06-28T21%3A47%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-version&_sort=-date&page=1

Only a few have UAF addresses, though...

Comment 13

[Jon Coppeard (:jonco)]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11)
I'm not currently investigating this.  I wasn't able to find a link with bug 1352430.  

The associated intermittent test failures bug 1366083 and bug 1366153 have stopped happening but crashes with this signature are still occurring.

The crashes mostly seem to happen doing type monitoring after coming out of JIT code.  Jan, do you know who would be a good person to investigate further?

Comment 14

[Jan de Mooij [:jandem]]

Sean since you're on Linux, maybe you can try to repro with rr?

Comment 15

[Sean Stangl [:sstangl]]

Jan, I'm not able to reproduce the failure on Fedora x86_64. That may be expected: Comment 6 indicates that the failure is only on other platforms.

Comment 16

[Jan de Mooij [:jandem]]

(In reply to Sean Stangl [:sstangl] from comment #15)
> Jan, I'm not able to reproduce the failure on Fedora x86_64. That may be
> expected: Comment 6 indicates that the failure is only on other platforms.

OK but maybe we can use Try debugging? We should fix this bug somehow.

Comment 17

[Wennie]

Hi Jon:

I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them.

Thanks!

Wennie

Comment 18

[Gian-Carlo Pascutto [:gcp]]

>Jan, I'm not able to reproduce the failure on Fedora x86_64. That may be expected: Comment 6 indicates that the failure is only on other platforms.

You can get a loaner machine from ServiceNow with the right configuration if that's easier to debug than on try.

Comment 19

[Sean Stangl [:sstangl]]

Do we know if this crash is still occurring? It looks like Bug 1366083 had some diagnostic patches landed to look into the issue, but no movement there either, and an extremely small failure rate.

Comment 20

[Andrew McCreight [:mccr8]]

I think marking it incomplete is okay...