bugGnash - The GNU Flash player - Bugs: bug #38084, Superclass prototype method call...


bug #38084: Superclass prototype method call failure

Submitted by:  bl0ckeduser <bl0ckeduser>
Submitted on:  Mon Jan 14 17:59:51 2013  
Category: ActionScriptSeverity: 3 - Normal
Release: masterStatus: Confirmed
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun Feb 3 17:37:41 2013, comment #20:

Pushed as commit:e05d45cf63944873dbdba4f89c78d17bf36e7c12
thank you

Sandro Santilli <strk>
Project Member
Sat Feb 2 16:00:57 2013, comment #19:

Here's a new version of the patch where I pasted the test before the
block with _global.Array.prototype = "string".

I checked the test counts for versions 5, 6, 7, 8 before and after the
patch and in all cases the number of expected failures and total tests
run increased by 1, so there are no regressions.

I also ran all the versions in the Adobe player and in each case I
obtained 0 failures and 0 expected failures.

(file #27369)

bl0ckeduser <bl0ckeduser>
Sat Feb 2 08:45:49 2013, comment #18:

Yeah, maybe the _global.Array.prototype = "string" line ?
That line could also be instructive, btw....

Sandro Santilli <strk>
Project Member
Fri Feb 1 22:40:59 2013, comment #17:

strk: Just tried, it also happens for me with 11,2,202,261.
What is strange is that when I compile the test alone
with makeswf with any SWF target versions, it works:

$ cat >test.as
function X() { trace('X ctor'); }
X.prototype = new Array();
trace("creating new object");
o = new X();
o.push("Array data");
$ rm out.swf ~/.macromedia/Flash_Player/Logs/flashlog.txt
$ makeswf -v 8 test.as >/dev/null
$ flashplayerdebugger out.swf
$ tail ~/.macromedia/Flash_Player/Logs/flashlog.txt
creating new object
X ctor
Array data

I suppose I must have overlooked a subtle detail in the
array.as file, sorry.

bl0ckeduser <bl0ckeduser>
Fri Feb 1 18:39:06 2013, comment #16:

bl0ckeduser, your new test fails for me with adobe player when compiled at versions 6 to 8. Succeeds with version 5.
Can you confirm ? The player I'm testing is LNX 10,0,12,10

Sandro Santilli <strk>
Project Member
Tue Jan 29 00:58:28 2013, comment #15:

Here is a patch that adds the test to the file

It is again in git-format-patch format.

(file #27339)

bl0ckeduser <bl0ckeduser>
Mon Jan 28 09:11:13 2013, comment #14:

Excellent work. Could you provide a patch to include this in the Array test in actionscript.all ?

Putting this in Inheritance.as may be more appropriate but it is tricky because tehre's a distinction between "builtin" types and "AS-defined types" which isn't clear and could be the source of other bugs on itself.

THere was a list to a list of natives vs. non-native functions/constructors somewhere but can't remember right now. Maybe on the wiki, maybe in a ticket, maybe somewhere else.

Anyway the safest is to put this in the Array.as test for now (and there could be other similar ones, like XML...)

Sandro Santilli <strk>
Project Member
Sun Jan 27 14:50:39 2013, comment #13:

I have modified the test to use the Array class
and the push and pop methods:

function X() { trace('X ctor'); }
X.prototype = new Array();
trace("creating new object");
o = new X();
o.push("Array data");

gnash master outputs this:

3418:1] 106 TRACE: creating new object
3418:1] 106 TRACE: X ctor
3418:1] 106 TRACE: undefined

and Adobe Flash 11,2,202,261 outputs this:

creating new object
X ctor
Array data

bl0ckeduser <bl0ckeduser>
Fri Jan 25 23:25:44 2013, comment #12:

Here is the log of TEST2 running in the Adobe player, version
"LNX 11,2,202,261":

About to instanciate an SC2 now
XPASSED: ret == true [./XMLSocketTest.as:123]

      • Security Sandbox Violation ***

Connection to FSCommand:quit halted - not permitted from file:///home/b
-- Browser scripting URLs may only be executed using the getURL and nav
igateToURL functions.
Warning: fail is not a function

Because the Adobe player did not seem to like the fail function, I
changed it to a trace. I got the same results but at the end of the
log, after some time, the following appeared:

instance onConnect called


Here it is in gnash with the "alternate this" patch:

14529:1] 2474 TRACE: -- RUNNING TEST2 --
14529:1] 2474 TRACE: About to instanciate an SC2 now
14529:1] 2475 ERROR: Trying superclass prototype call hack
14529:1] 2475 SECURITY: Load from host localhost.localdomain granted (d
14529:1] 2627 ERROR: getaddrinfo() needed to change localhost, check yo
ur /etc/hosts file!
14529:1] 2628 TRACE: XPASSED: ret == true [./XMLSocketTest.as:123]
14529:1] 2628 TRACE: ENDOFTEST
PASSED: consistency check: last trace from run of test (ENDOFTEST) mat
ches pattern (ENDOFTEST)

I also tried running the alternate-this version without the code that
stops it when ENDOFTEST is reached and with "fail" replaced with "trace",
this resulted in the following additional trace:

23215:1] 2117 TRACE: SC1 prototype onConnect called

I believe this is indeed the incorrect behaviour that you mention.

Note: I have run the logs through "fold -71" to make them fit well
in the email format.

bl0ckeduser <bl0ckeduser>
Fri Jan 25 08:38:28 2013, comment #11:

I merged your test in the testsuite, as an expected failure.
If you read it (test2 in testsuite/misc-ming.all/XMLSocketTest.as) you'll see that the "alternate this" idea is likely to fail because the proprietary player doesn't seem to be calling any of the events (onConnect/onData/onClose).

Can you confirm that ?
In order to test the proprietary player you need a standalone debugging version of it and substitute the gnash call line with flashplayer in XMLSocketTester (generated in build tree, under testsuite/misc-ming.all)

The commit adding your test is df19f2f0cf0b996090faaff81827a073b600ad10

Sandro Santilli <strk>
Project Member
Mon Jan 21 11:00:09 2013, comment #10:

I made a few more tests this weekend and found a simpler testcase:

function X() { trace('X ctor'); }
X.prototype = new XMLSocket();
trace("creating new object");
o = new X();
trace(o.connect("localhost", 2229));

With the proprietary player you'll get "false" returned from o.connect, while with Gnash you'll get "undefined" (due to the impossibility to find "this" pointing at the object that would be created by XMLSocket constructor.

The idea of an "alternate this" is interesting but it could be maybe even better to have a proper "this" constructed as the very first thing.

More tests would be nice.
For example, can we think of other builtin objects (needing a strong-typed "this") that we can try to chain into a single inheritance to see if all functions work on the same object even if expecting different type of "this" objects ?

bl0ckeduser: good tests are very important. even if they are known to fail (you can mark them so with the xcheck/xcheck_equals). We mostly used tests as a way to reverse engeneer the proprietary player.

Sandro Santilli <strk>
Project Member
Fri Jan 18 00:21:25 2013, comment #9:


I have written a patch that fixes the issue. I have run the testcases via
"make check" both on a clean master copy of the gnash git repo and with my
patch applied. Running a diff -u of the obtained results (summarized via
the analyse-results.sh script) shows that with my patch, the total number
of passes was 47428, and without, 47427. (I'm not sure why this is). My
patch did not introduce any failures. However, both with and without my
patch applied I obtained the following testing errors:

Unexpected failures follow:
--=[ testsuite/actionscript.all ]=--
FAIL: astests-v6-Runner: no onSoundComplete arrived after 3 seconds
FAIL: astests-v6-Runner: Tests run 107 (expected 111) [ [./Sound.as:31]]
FAIL: astests-v7-Runner: no onSoundComplete arrived after 3 seconds
FAIL: astests-v7-Runner: Tests run 107 (expected 111) [ [./Sound.as:31]]
FAIL: astests-v8-Runner: no onSoundComplete arrived after 3 seconds
FAIL: astests-v8-Runner: Tests run 107 (expected 111) [ [./Sound.as:31]]

So my patch has not introduced any regressions.

I hope I have not made any coding mistakes and that the code quality is
good enough for your standards.

I have enclosed it in "git-format-patch" format.

(file #27297)

bl0ckeduser <bl0ckeduser>
Wed Jan 16 23:03:23 2013, comment #8:

strk: Thanks for the tips. It will probably take me
some time to figure out how to fix the issue but
when I do find a way I will make sure to send a
patch and check that it doesn't cause any regressions.

bl0ckeduser <bl0ckeduser>
Wed Jan 16 08:40:28 2013, comment #7:

bl0ckeduser your help is very precious and more tickets are welcome for other old-versioned SWF showing issues in Gnash (not in this ticket).

Even of more help is your willingness to provide self-contained testcases for a start and eventually also the actual patches to fix those problems.

I'm very happy to see someone interested in compatibility with handling old SWF versions. Recently it looked like all people wanted was AVM2 support :)

Please make sure you have all the build dependencies needed to run the testsuite and give it a run to see where we're up to.
Many issues are already encoded as "expected failures" in the current testsuite.

This one probably wasn't as I also looked into actionscript.all/Inheritance.as and didn't see any expected failure in there.

Once you get full testsuite support you can see the effects of changing that line you found in ASHandlers.cpp. Running "make check" would show you unexpected successes for bugs that it'll fix and unexpected failures for bugs that it'll introduce (if any).

Sandro Santilli <strk>
Project Member
Wed Jan 16 00:25:37 2013, comment #6:

strk: That is indeed the relevant part. As for single indirection, I will try to write another testcase tomorrow when I'm back to my Linux system.

I agree that the ActionScript code I have submitted is a quite ugly corner-case. I wrote it to demonstrate a subtle case where Gnash does not have good compatibility with the Adobe Flash player. I sent this report because I am interested in
preserving some historical Flash software without depending on
Adobe binaries, but I think fixing cases like this could also generally improve Gnash, at least insofar as it is meant
as a free alternative to the Adobe player.

If this may help, when I was debugging the
old chat client that first gave me this error, I noticed
that the following "if" in ASHandlers.cpp got followed
prior to the method call failure error message:

if (func && func->isBuiltin()) {
// Do not construct super if method is a builtin
// TODO: check if this is correct!!
super = 0;

BTW, I know of a few other programs (mostly games) that
have slight graphical or sound issues running in Gnash, I can
give you links to the .SWF files and give nontechnical info
about the glitches if you want.

bl0ckeduser <bl0ckeduser>
Tue Jan 15 18:45:41 2013, comment #5:

Oh it's also a double indirection:

myXML_f inheriths XMLSocket
myXML_sc inherits myXML_f
myXML is an instance of myXML_f, and is what .connect is called against

bl0ckeduser: can it be reproduced with a single indirection ?
And, can it be reproduced without the "this.superclass" calls ?

Sandro Santilli <strk>
Project Member
Tue Jan 15 18:43:01 2013, comment #4:

Here's the relevant snippet (probably):

function myXML_f() {}
myXML_f.prototype = new XMLSocket();

function myXML_sc() {
this.superclass = myXML_f;

Maybe we found an use for those _constructor_ and "constructor" methods ... Sounds like an interesting task

Sandro Santilli <strk>
Project Member
Tue Jan 15 18:14:35 2013, comment #3:

XMLSocket.connect can only be called on native XMLSocket objects. For Gnash, that means an as_object that has an XMLSocket_as as a proxy. Proxy objects are added by special native constructor functions.

As strk said the obvious problem is that the object isn't a native XMLSocket type. But it's likely to be correct that the connect() function call should really fail for non-XMLSockets, because the socket connection really has to be made, and that is only doable through a native function.

I suspect the most likely cause of the bug is the construction of the object, which should call the XMLSocket native constructor and evidently doesn't. The ActionScript code certainly does some ugly fiddling there.

Benjamin Wolsey <bwy>
Project Member
Mon Jan 14 20:37:25 2013, comment #2:


First of all, thank you for answering so soon.

After some work, I have finally succeeded in creating
a testcase by modifying XMLSocketTest.as. This file, once
compiled, will succesfully connect to the specified
server when run using the Adobe Flash player, but will
fail to connect when run in the Gnash player.
And the error is the same as the one I told about earlier.
Here it is again from the debug log of running
XMLSocketTest.swf in Gnash:

PC:5948 - EX: ActionCallMethod
method name: [string:connect]
method object/func: [object(gnash::as_object):0x7f755a50e8f0]
method nargs: 2
938:1] 4743 ACTIONSCRIPT ERROR: ActionCallMethod: Function requiring gnash::XMLSocket_as* as 'this' called from gnash::as_object* instance.

To test whether the Flash file succesfully connected,
I ran the following in an other window before starting
the Flash file:

$ sudo nc -l 2229

To run the Flash file in the Adobe Flash player, I had
to do lots of cumbersome work.

First, I had to have the following lines in
the file ~/mm.cfg:


Them, I had to setup a permissive policies daemon
on my local machine. Finally I had to install the
programs "LocalContentUpdater" and "flashplayerdebugger"
from Adobe and run:

$ sudo LocalContentUpdater -a XMLSocketTest.swf
$ flashplayerdebugger XMLSocketTest.swf

When I ran the SWF with the Adobe Player, I soon obtained
the words "Plain Text" in the netcat window.

However, when I ran it with the latest Gnash compiled
from Git master sources, I obtained no such text in
the netcat window (and I obtained the debug error
pasted above).

Please find enclosed the modified version of
XMLSocketTest.as which only fails in Gnash but
doesn't in Adobe Flash. I have not made a git patch
because I have only changed one file. If you want,
I can make a git patch.

Thank you

(file #27262)

bl0ckeduser <bl0ckeduser>
Mon Jan 14 18:14:05 2013, comment #1:

The useful error message:

2669:1] 6705 ACTIONSCRIPT ERROR: ActionCallMethod: Function
requiring gnash::XMLSocket_as* as 'this' called from gnash::as_object* instance.

Is telling you that the ActionScript code is calling a built-in method against a non-native XMLSocket instance.

This may be expected to work or not.
Are you in a position to verify this by writing a small, focused testcase ?

Note: there is an existing testcase for XMLSocket class, you may extend that one: see testsuite/misc-ming.all/XMLSocketTest.as and XMLSocketTester.sh

Sandro Santilli <strk>
Project Member
Mon Jan 14 17:59:51 2013, original submission:


I'm trying to run an old Flash (SWF version 6) chat program in
Gnash. It uses XML sockets. The program runs fully on the
latest Adobe Flash player, but on Gnash (checked out from
Git in early January 2013) the XML socket connection fails,
and I've traced this failure to the following line, decompiled
from the SWF file using the utility flare:

var connectSuccess = this.connect(this.host, this.port);

When the program is run in Gnash, the variable connectSuccess
gets assigned the value "undefined" and the connection fails.

Looking back at the debugging logs I see:

PC:4753 - EX: ActionNew
---new object: XMLSocket
2669:1] 2265 DEBUG: Loading native class XMLSocket
After execution: PC 4753, next PC 4754, stack follows
Stack: "[object(gnash::Function):0x7f92b907c890]"
| "[string:prototype]"
| "[object(gnash::XMLSocket_as):0x7f92b903c1a0]"

PC:4754 - EX: ActionSetMember
-- set_member [object(gnash::Function):0x7f92b907c890].

Then, several lines later:

set_member [object(gnash::as_object):0x7f92b83c97d0]

And later again:

PC:4951 - EX: ActionCallMethod
method name: [string:connect]
method object/func: [object(gnash::as_object):0x7f92b83c97d0]
method nargs: 2
2669:1] 6705 ACTIONSCRIPT ERROR: ActionCallMethod: Function
requiring gnash::XMLSocket_as* as 'this' called from gnash::as_object* instance.

As far as I can tell, an object (0x7f92b83c97d0) is
being given as superclass a function (0x7f92b907c890)
which has as prototype an XML_Socket (0x7f92b903c1a0),
and then calling of the method "connect" on the object
fails. "connect" is part of the XML_Socket class.

The relevant code appears to be in the method
ActionCallMethod of the file libcore/vm/ASHandlers.cpp.

Now this is mostly guesswork on my part, as I do not
know C++ or ActionScript very well, but I'd certainly
like to be able to contribute to the improvement of this
software, because Adobe only distributes binary versions
of its player for a few select platforms, and nothing
guarantees that it will continue to do this in the future.

I have tried to fix this bug myself but it has proven
too confusing due to my lack of C++ skills.

bl0ckeduser <bl0ckeduser>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #27297:  0001-Ugly-but-working-fix-for-bug-38084.patch added by bl0ckeduser (2kB - text/x-diff - Patch to fix bug 38084)
file #27262:  XMLSocketTest.as added by bl0ckeduser (4kB - application/octet-stream - Modified XML socket test case, see post above)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by bl0ckeduser (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Feb 2 16:00:57 2013bl0ckeduserAttached File-=>Added 0001-Add-test-case-for-array-prototype-inheritance.patch, #27369
    Tue Jan 29 00:58:28 2013bl0ckeduserAttached File-=>Added 0001-Add-test-case-for-array-prototype-inheritance.patch, #27339
    Fri Jan 18 00:21:25 2013bl0ckeduserAttached File-=>Added 0001-Ugly-but-working-fix-for-bug-38084.patch, #27297
    Wed Jan 16 08:40:28 2013strkStatusNone=>Confirmed
    Mon Jan 14 20:37:25 2013bl0ckeduserAttached File-=>Added XMLSocketTest.as, #27262
    Mon Jan 14 18:14:22 2013strkCategoryNone=>ActionScript

    Back to the top

    Powered by Savane 3.1-cleanup