973791 - Assertion failure: obj->getSlot(slot).isUndefined()

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: linux stack

found via bughunter on

Steps to reproduce:

-> Load http://www.southwalesargus.co.uk/li/crime.in.CF81%209FU/ in a windows 7 debug Trunk Build
-> Watch the page to load / after a few seconds 

Assertion failure: obj->getSlot(slot).isUndefined()

seems hit all debug build on all branches and platforms

will see that i get a testcase

Comment 1

[Jan de Mooij [:jandem]]

I can repro this on OS X. There's an object stored in that slot instead of undefined.

Comment 2

[Jan de Mooij [:jandem]]

The constructor with the TypeNewScript is MarkerClusterer: http://www.southwalesargus.co.uk/resources/static/standard/texts/js/markerclusterer.js, line 52.

We're calling this.setMap(e) there and this somehow marks the object's properties as unknown. Then we look for this script on the stack and call JSObject::rollbackProperties to delete this property:

    ((JSShape *) 0x12dfee268) enumerate JSString* (0x12b3baac0) = jschar * (0x12b3baad0) = "gm_accessors_"
: slot 12 = <Object at 0x12dfecac0>

We expect it to have its initial undefined value because it's not yet initialized, but in this case it is.

Comment 3

[Jan de Mooij [:jandem]]

Brian can you take this? Thanks!

Comment 4

[Jan de Mooij [:jandem]]

I think the problem is that we're trying to rollback the gm_accessors_ property, but this property is not added to the object in the constructor but in some other script under the this.setMap(e) call, so we don't want to delete it.

Comment 5

[Jan de Mooij [:jandem]]

Ah, we're actually trying to rollback the prevZoom_ SETPROP:

function MarkerClusterer(e, a, d) {
    ...
    this.zoomOnClick_ = b.zoomOnClick || true;
    this.setMap(e);
    this.prevZoom_ = this.map_.getZoom();
    ....
}

But the setMap(e) call ends up adding new properties, confusing the rollback code.

Comment 6

[Daniel Veditz [:dveditz]]

Is that a potential security problem? If so how bad?

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Daniel Veditz [:dveditz] from comment #6)
> Is that a potential security problem? If so how bad?

I'm not sure. Brian, what do you think? Can you please take a look at this?

Comment 8

[Brian Hackett [Laid off!]]

I can't reproduce this.  Can anyone still reproduce the bug on the current version of the website / trunk?

Generally this sort of thing shouldn't be a security risk, since the definite properties are tied directly to the properties added on the object at its creation.  If we think a property is definite but it's not, there could be a null deref when the property is accessed before it is assigned to yet.

Comment 9

[Bob Clary [:bc] (inactive)]

I checked and this assertion was only seen in automation for this one url on 2014-02-17. I resubmitted it and could not reproduce. It was originally seen for Aurora 29/Nightly 30 Linux/OSX/Windows. This appears to have been due to transitory content or a regression which was quickly fixed. Unfortunately we do not have a regression range or test case.