553960 - Crash on manipulating node.data / addCallback (from AS) [@ Flash Player@0x8cbe0]

Status: RESOLVED INCOMPLETE

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Olivier Gambier]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 

I'm opening this ticket as to provide more informations about:
http://crash-stats.mozilla.com/report/index/bp-66901455-89ea-49cd-b579-be19d2100321
(or http://crash-stats.mozilla.com/report/index/bp-5cdd516d-2c11-4ecf-ba90-7d1aa2100321 / others)

Reproducing this involves manipulating the data property on the object node then attaching a callback (both operations from AS).

Technically that is:

// Allow communication with JS
Security.allowDomain("*");
Security.allowInsecureDomain( "*" );

// Call on JS so that node.data is changed
ExternalInterface.call("(function(){\
        var node = document.getElementsByTagName('object')[0];\
        node.data = 'thing';})"); 

// Attach a callback onto us
ExternalInterface.addCallback( "bindTestCrash", crash );

(crash being whatever empty method)

I don't know what's done inside the addCallback method (decompiling playerglobal.swc shows only native calls for the relevant part), and trying to reproduce this with only the js side calls (__flash__addCallback) doesn't seem to crash 

If that helps, I can provide AS testcases.

Reproducible: Always

Actual Results:  
Crash

Expected Results:  
Not crash. None of Opera/Safari/Chrome do crash.

Comment 1

[Olivier Gambier]

Here:
- http://blog.zoomodev.com/public/crashff/Crash.as <-- AS source
- http://blog.zoomodev.com/public/crashff/Crash.html <-- !!!! will crash

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #1)
> Here:
> - http://blog.zoomodev.com/public/crashff/Crash.as <-- AS source
> - http://blog.zoomodev.com/public/crashff/Crash.html <-- !!!! will crash

Hey,
could you reproduce it on an other platform than Mac?
This doesn't seems to crash on my linux box (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3pre) Gecko/20100321 Namoroka/3.6.3pre)

Anyway, thanks for the testcase and the nice description!

Vivien

Comment 3

[Olivier Gambier]

I haven't tried. Although, this stacktrace
http://crash-stats.mozilla.com/report/index/bp-769e1b55-f164-444f-ad29-c91862100321
(which I generated with ff3.5/mac) matches this one http://crash-stats.mozilla.com/report/index/d16fe349-1351-4b9b-a2a2-982b42100316 (if I understand well how that stuff works) and this later one was a Windows user.

Please note though that my testcase seems to involve a race condition, and that it doesn't *always* crash - you may need to reload a number of times.

I'll try to crash win/nux later when I get a chance.

Comment 4

[Olivier Gambier]

Crashing windows as well (clean profile):
http://crash-stats.mozilla.com/report/index/bp-1f75ecad-510b-441e-9c92-256f22100322

I really am not familiar with NPAPI code but I don't think this is platform specific...

If this is of any relevance, this is flash version 10.0.32.18 (win) and 10.0.42.34 (mac).

Comment 5

[Olivier Gambier]

For the record, Namoroka crashes as well (http://crash-stats.mozilla.com/report/index/3c680efc-e888-421f-bd16-758c52100322), but interestingly, it appears that Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a3) Gecko/20100315 MozillaDeveloperPreview/3.7a3 doesn't.

Hope all this helps.

Comment 6

[timeless]

Signature	Flash Player@0x8cbe0
UUID	66901455-89ea-49cd-b579-be19d2100321
Time 	2010-03-21 18:03:09.295994
Uptime	39
Last Crash	55 seconds before submission
Product	Firefox
Version	3.6
Build ID	20100115132715
Branch	1.9.2
OS	Mac OS X
OS Version	10.5.8 9L31a
CPU	x86
CPU Info	GenuineIntel family 6 model 7 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x75721c08
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	Flash Player 	Flash Player@0x8cbe0 	
1 	Flash Player 	Flash Player@0x31c9bc 	
2 	XUL 	nsNPAPIPluginStreamListener::OnDataAvailable 	modules/plugin/base/src/nsNPAPIPluginInstance.cpp:600

Flash Player  	 	611C96B58EC39919D577E20F8C1D19470  	Flash Player

Signature	nsNPAPIPluginStreamListener::OnDataAvailable(nsIPluginStreamInfo*, nsIInputStream*, unsigned int)
UUID	3c680efc-e888-421f-bd16-758c52100322
Time 	2010-03-22 04:05:50.865399
Uptime	20
Last Crash	30166 seconds before submission
Product	Firefox
Version	3.6.3pre
Build ID	20100321033650
Branch	1.9.2
OS	Mac OS X
OS Version	10.5.8 9L31a
CPU	x86
CPU Info	GenuineIntel family 6 model 7 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x73617263
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0xffff07c7 	
1 		@0xffff1221 	
2 		@0xffff086d 	
3 	XUL 	nsNPAPIPluginStreamListener::OnDataAvailable 	modules/plugin/base/src/nsNPAPIPluginInstance.cpp:679

Signature	memmove | nsNPAPIPluginStreamListener::OnDataAvailable(nsIPluginStreamInfo*, nsIInputStream*, unsigned int)
UUID	1f75ecad-510b-441e-9c92-256f22100322
Time 	2010-03-22 03:47:48.503039
Uptime	55
Product	Firefox
Version	3.6
Build ID	20100115144158
Branch	1.9.2
OS	Windows NT
OS Version	6.0.6002 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x73617263
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	mozcrt19.dll 	memmove 	MEMCPY.ASM:280
1 	xul.dll 	nsNPAPIPluginStreamListener::OnDataAvailable 	modules/plugin/base/src/nsNPAPIPluginInstance.cpp:679

so the first mac crash seems to be a bug in Flash, the second one is *probably* the same bug in Flash. The third one is odd, since it implies there's no flash floating around.

Comment 7

[Olivier Gambier]

(In reply to comment #5)
> but interestingly, it appears that Mozilla/5.0 (Macintosh; U; Intel Mac OS X
> 10.5; en-US; rv:1.9.3a3) Gecko/20100315 MozillaDeveloperPreview/3.7a3 doesn't.

Scratch that.
http://crash-stats.mozilla.com/report/index/f708a719-71ab-4a6d-909e-2abf52100322

FWIW: a debug flash player will throw "Error #2044: IOErrorEvent text=Error #2036" (that is "load never completed" - see http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/runtimeErrors.html - which kind of make sense, given we are altering "data" on the object node), just before Firefox crashes.

Comment 8

[Pascal Chevrel (relman team) -> :pascalc]

Marking as New

Comment 9

[Jet Villegas (inactive)]

Picking this up.

Comment 10

[Shelby Moore]

This bug seems to be related to a series of problems I am seeing on Windows XP SP2, with Flash 10.1.85.3 and tested on both Firefox 3.5.3 and 3.6.x.  Tested on 2 different machines.

1) In both FF and Google Chrome, if I do anything to Flash <object>, e.g. hide it by any means, appendChild() meaning move it to another node of the displayed document, then the Flash is reloaded, which means my AS3 code in the SWF gets restarted as if it were just loaded. Note the conflicting reports at following links:

http://www.ebessette.com/d/software/ToggleFlash
http://forums.adobe.com/message/131586#131586

2) On FF, but not on Chrome, if I do any of the above which cause the Flash object to reload (or maybe it is only the appendChild() because I didn't write a journal every possible permutation of things), then FF refuses to register any more ExternalInterface.callback() and it loses the ones I had register prior to the reload.

What I have concluded is that it is very unreliable to hide Flash objects, and move them around the displayed DOM tree using appendChild(), and it is better to just reload them by doing a separate swfobject.embedSWF() for each time one wants to diplay.  Then put logic in your AS3 code to pass in a "jump to" what ever was the state you wanted to restore in your Flash object.

The better solution would be if browsers (npruntime?) and/or Flash Player fixed these bugs.

Comment 11

[Shelby Moore]

I don't know if these apply:

http://code.google.com/p/doctype/wiki/ArticleFixingFlashExternalInterface
http://dangerouslyawesome.com/2006/10/another-swfobject-problem-deproblemed/

Comment 12

[Benjamin Smedberg]

I'm closing a lot of bugs which are filed as Adobe Flash bugs which are either irrelevant, not actionable, or not serious enough to track in the Mozilla bug tracker. For the most part, Flash bugs should be filed in Adobe bugbase, and we'll only track a few highly-critical issues in the Mozilla tracker.

Comment 13

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.