544140 - flash.sampler.getLexicalScopes() can return objects for which toString() throws exception

Status: VERIFIED INVALID

(Tamarin Graveyard :: Virtual Machine, defect, P2)

Description

[Mike Morearty]

Attachment: Sample to demonstrate the problem

flash.sampler.getLexicalScopes() returns an array of objects that make up the lexical scopes of an object.  However, if you call toString() on each of the values in the returned array, the toString() call will sometimes throw an exception.  This seems to happen when the object represents a function.  (Don't take my use of the word "function" too literally -- I am using it in a general hand-waving kind of way.)

I don't know if ECMA has anything to say about objects for which toString() fails, but I've never seen that happen before (unless, of course, a class explicitly overrides toString() and throws an exception).

If this is okay with ECMA, then perhaps this is not a problem.

Simple repro case: compile and run this:

-- begin --

import flash.sampler.*;

function f() {
    return function() { }
}

trace(getLexicalScopes(f()));

-- end --

Output:

-- begin --

ReferenceError: Error #1069: Property toString not found on <anonymous> and there is no default value.
	at Array$/_join()
	at Function/<anonymous>()
	at avmplus::System$/trace()
	at global/trace()
	at global$init()

-- end --

For a slightly fancier repro case, showing the problem with both member functions of a class and regular top-level functions, see the attachment x.as.

Comment 1

[Lars T Hansen]

Probably the activation object, which is optimized out if it's not needed.  You should see the same problem if 'f' contains try-catch or a 'with' statement.

Comment 2

[Lars T Hansen]

I take that back - it probably is the activation object, but involving a function in the mix is probably necessary; even if try-catch and 'with' also force the activation object to be there, getLexicalScopes won't expose it.

Comment 3

[Mike Morearty]

Progress update: Just last week, on Friday, I was digging into this, and did make some progress, but the fix is tricky.  I am tempted to punt it and not fix, BUT first I need to get a better handle on whether the change is actually necessary – there is a chance that we actually need this change in order to get useful profiler results.  I think we probably don't need the change; if that's the case, then I'll want to punt this one.  But if we do need the change, I'm halfway to fixing it.

Comment 4

[Tommy Reilly]

activation objects aren't otherwise visible to scripting code and hence aren't normal objects subject to ECMAscript rules.  I don't think there's a bug here.

Comment 5

[Mike Morearty]

Okay, thanks Tommy.  In addition, I've done some testing with the Flash Builder debugger, and it works fine with the current behavior, as Tommy suspected.

Resolving as invalid.