Open Bug 1288393 Opened 4 years ago Updated 3 years ago

Uninitialised value use pertaining to mozilla::dom::MediaQueryList

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

Tracking Status
firefox50 --- affected

People

(Reporter: jseward, Unassigned)

Details

Attachments

(2 files)

STR:

DISPLAY=:1.0 /home/sewardj/VgTRUNK/mozhx/Inst/bin/valgrind \
  $MOZVFLAGS --track-origins=no --num-callers=50 \
  ./ff-O2-linux64/dist/bin/firefox-bin -P dev -no-remote 2>&1 | tee spew-07-8

and make it load techcrunch.com
My impression is that, in nsIDocument::MatchMedia(const nsAString& aMediaQueryList),
a MediaQueryList object is created right at the start of the routine, and at
some point later on, its mMatches field is passed to the JS world, where it causes
the complaints shown in comment 1, which are within SpiderMonkey.

Some digging reveals that MediaQueryList::MediaQueryList doesn't initialise
mMatches.  So a simple fix is to initialise it there.  Somehow this doesn't
feel right, though .. it seems to imply we are using mMatches even though
mMatchesValid is false.
The obvious, but possibly wrong, fix.
It appears that both MediaQueryList's members and their initialisation
in MediaQueryList::MediaQueryList haven't changed in a long time.  But
this bug is new; I haven't seen it before.

So I wonder if it is a use of MediaQueryList that has changed recently?
Possibly somehow related to bug 1264891?
(In reply to Julian Seward [:jseward] from comment #3)
> The obvious, but possibly wrong, fix.

[from irc]
<dbaron> [..] I'm worried the patch would cover up some other problem...

My (possibly feeble) working theory is that a MediaQueryList object
with uninitialised mMatches is constructed.  Then the object is taken
to pieces and the pieces, including mMatches, are handed to JS-land,
which eventually does a branch on mMatches.  That's why we get
complaints about uninitialised values in SM.  Or, maybe the object is
handed intact to JS-land.  Doesn't really matter which.  So maybe
we're looking for a bit of JS which pokes mMatches without first
checking mMatchesValid?  Total guess ..

I don't know how to proceed on this.  Could you please advise?
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.