54431 - crash when trying to play realplayer plugin in javascript window

Status: VERIFIED DUPLICATE of bug 54121

(Core :: JavaScript Engine, defect, P1)

Description

[shrirang khanzode]

Build:2000092711 branch
Plugin :realplayer G2
This test is from the suite provided by REAL.

Steps:
1 Go to the link above
2 Click on the image with text "Wanna hear some really bad singing?" to it's   
right at the center of the page.
3 Observe a javascript window launches, trying to load realplayer
4 Also a small window saying "Object :KeyEvent"  pops up
5 Press Ok to close this window
6 Now click on the Arrow button to play the music file
7 The browser crashes

Comment 1

[ekrock's old account (dead)]

Marking crash. Nominating for rtm consideration. Setting P1--high profile 
partner (RealPlayer). Note that using JS to pop up a window to play media 
content is a common technique on web sites if they use media content in the 
first place.

Something to investigate: is the arrow:
a) just a regular RealPlayer control? Or is it 
b) trying to use LiveConnect to call the plug-in's Java API from JavaScript?

If a), this should work in Moz/N6 with current RealPlayer released versions.
If b), it should fail silently with current RealPlayer released versions but not 
crash.

Comment 2

[av (gone)]

Marc, would you please take a look when you have a spare cycle?

Comment 3

[ekrock's old account (dead)]

To clarify: Marc, we're hoping you can actually take this on and fix it for RTM. 
(Please? ;-> ) If you can't, please let us know & we'll try to find someone 
else. Thanks!

Comment 4

[Marc Attinasi]

Yes, I'll look at it right away.

Comment 5

[Marc Attinasi]

This is crashing in JavaScript, nothing about plugins in the stack.

I'm trying to narrow down the player window source, it is pretty complicated and
is server-generated.

My guess is that this is not even a plugin issue, but instead is a scripting
engine issue. Here is the stack, maybe jst can make some sense out of it (please
CC anybody else who might be able to):

NewParseNode(JSContext * 0x04ef0c90, JSToken * 0xe7b37688, int 0xffffffff) line
137 + 6 bytes
Variables(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 1661 + 26 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 1412 + 17 bytes
Statements(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 629 + 17 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 1486 + 17 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 902 + 17 bytes
Statements(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 629 + 17 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 1486 + 17 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 897 + 17 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 902 + 17 bytes
Statements(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f20c) line 629 + 17 bytes
FunctionBody(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSFunction *
0x05019ac0, JSTreeContext * 0x0012f20c) line 347 + 17 bytes
FunctionDef(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f3e4, int 0x00000000) line 513 + 21 bytes
FunctionStmt(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f3e4) line 599 + 19 bytes
Statement(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f3e4) line 879 + 17 bytes
Statements(JSContext * 0x04ef0c90, JSTokenStream * 0x014b9038, JSTreeContext *
0x0012f3e4) line 629 + 17 bytes
js_CompileTokenStream(JSContext * 0x04ef0c90, JSObject * 0x01385178,
JSTokenStream * 0x014b9038, JSCodeGenerator * 0x0012f3ac) line 261 + 20 bytes
CompileTokenStream(JSContext * 0x04ef0c90, JSObject * 0x01385178, JSTokenStream
* 0x014b9038, void * 0x04ef0d10, int * 0x00000000) line 2657 + 21 bytes
JS_CompileUCScriptForPrincipals(JSContext * 0x04ef0c90, JSObject * 0x01385178,
JSPrincipals * 0x04836240, const unsigned short * 0x0149ba58, unsigned int
0x00001b42, const char * 0x050191e0, unsigned int 0x00000001) line 2736 + 23 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x04ef0c90, JSObject * 0x01385178,
JSPrincipals * 0x04836240, const unsigned short * 0x0149ba58, unsigned int
0x00001b42, const char * 0x050191e0, unsigned int 0x00000001, long * 0x0012f5c4)
line 3143 + 33 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x04ef0e40, const
basic_nsAReadableString<unsigned short> & {...}, void * 0x01385178, nsIPrincipal
* 0x0483623c, const char * 0x050191e0, unsigned int 0x00000001, const char *
0x00000000, basic_nsAWritableString<unsigned short> & {...}, int * 0x0012f620)
line 583 + 68 bytes
HTMLContentSink::EvaluateScript(nsString & {"//
// Plugin.js -- Plugin Object for theDial Player.
// Copyright (C) 1999-2000, theDial.com
// All Rights Reserved.
//
//    "}, nsIURI * 0x05013fa0, int 0x00000001, const char * 0x00000000) line 4610
HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x04eca5a4,
nsIStreamLoader * 0x05012230, nsISupports * 0x00000000, unsigned int 0x00000000,
unsigned int 0x00001b42, const char * 0x014742c0) line 4732 + 42 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x05012234, nsIChannel *
0x05012360, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned
short * 0x100a66c8 gCommonEmptyBuffer) line 121 + 78 bytes
nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x05011d30,
nsIChannel * 0x05012360, nsISupports * 0x00000000, unsigned int 0x00000000,
const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 1158 + 42 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const
0x05019c50, nsIChannel * 0x05012360, nsISupports * 0x00000000, unsigned int
0x00000000, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 1207
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x05019c50, unsigned int
0x00000000, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 1877 + 42
bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x0501c5f0,
nsIChannel * 0x04863ee4, nsISupports * 0x05012360, unsigned int 0x00000000,
const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 729
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0501c940) line 302
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0501df20) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x0501df20) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f299e0) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00280aa0, unsigned int 0x0000c0c5, unsigned int
0x00000000, long 0x00f299e0) line 1054 + 9 bytes
USER32! 77e71820()
00f299e0

Comment 6

[Marc Attinasi]

Attachment: Local testcase with no external script

Comment 7

[Marc Attinasi]

CC'ing rogerl as JavaScript engine owner. Please look at the attached stack
trace and se if it looks serious enough for RTM consideration.

To restate: I see nothing to suggest that this is a plugin problem. The crash
site callstack simply looks like the JS engine getting confused and
dereferencing destroyed objects (actually, I saw that in the debugger, the
object being dereferenced had all of it's fields set to 0xcdcdcdcd).

Since this is a P1 bug, I think it needs traction immediatly - the clock ticketh...

Comment 8

[rogerl (gone)]

Couldn't reproduce the steps (didn't see the 'bad snging' invitation) but got a 
GC crash anyway when trying some of the other links. The parser crash looks like 
a memory corruption - the token address is way bad, it shoud have been just 
a little higher than the tokenstream address. The GC crash implicated a 
"nsGenericElement::mScriptObject".

Comment 9

[Marc Attinasi]

Sorry Roger, I forgot to mention that the link specified is gone. I just clicked
on good ol' Mr. Kotter, but any of the links that call start_player should cause
it. Also, the attached testcase does the same.

To be honest, I'm not sure that there is much I can do with this. Can you
suggest a way I can help, or take the bug, or something?

Comment 10

[rogerl (gone)]

Sure, i'll take it for now - though i doubt it'll be an engine issue in the end.

Phil: can you try reproducing this under purify when you get a chance?

Comment 11

[ekrock's old account (dead)]

Brendan/Vidur/Heikki/Johnny/JBand -- Appears that in this window created by 
JavaScript, RealPlayer is crashing, and the problem is happening somewhere 
within the JavaScript engine. Can you offer any insight?

Comment 12

[Phil Schwartau]

Note: I do not have Purify yet...

Comment 13

[Marc Attinasi]

CC'ing self. If I can assist in some way, just ask.

Comment 14

[Phil Schwartau]

I am getting a completely different WinNT stack trace from the one above. 
Note: this is with code pulled from the trunk on 2000-10-11:


In the debug console: 

JS API usage error: the address passed to JS_AddNamedRoot currently holds an
invalid jsval.  This is usually caused by a missing call to JS_RemoveRoot.
The root's name is "nsGenericElement::mScriptObject".

In Visual c++:

+       (const char *) he->value        0x01924688 
"nsGenericElement::mScriptObject"




NTDLL! 77f7629c()
gc_root_marker(JSHashEntry * 0x046b7830, int 0x00000153, void * 0x05e8b030) line 
845 + 35 bytes
JS_HashTableEnumerateEntries(JSHashTable * 0x00b18120, int (JSHashEntry *, int, 
void *)* 0x002a22d9 gc_root_marker(JSHashEntry *, int, void *), void * 
0x05e8b030) line 364 + 15 bytes
js_GC(JSContext * 0x05e8b030, unsigned int 0x00000000) line 1059 + 21 bytes
js_ForceGC(JSContext * 0x05e8b030) line 871 + 11 bytes
JS_GC(JSContext * 0x05e8b030) line 1542 + 9 bytes
nsJSContext::GC(nsJSContext * const 0x05e8b1e0) line 1287 + 13 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x05e8b250, 
nsIDOMDocument * 0x05f8ecf4) line 365
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x05f8fdc0, nsIWidget * 
0x05e85bd4, nsIDeviceContext * 0x05e8b940, const nsRect & {...}) line 537
nsDocShell::SetupNewViewer(nsDocShell * const 0x05e84380, nsIContentViewer * 
0x05f8fdc0) line 2850 + 66 bytes
nsWebShell::SetupNewViewer(nsWebShell * const 0x05e84380, nsIContentViewer * 
0x05f8fdc0) line 350 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x05e843a0, nsIContentViewer * 0x05f8fdc0, 
const char * 0x012d11c4, nsISupports * 0x00000000) line 2484 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x05e843a0, nsIContentViewer * 0x05f8fdc0, 
const char * 0x012d11c4, nsISupports * 0x00000000) line 383
nsDocShell::CreateContentViewer(nsDocShell * const 0x05e84380, const char * 
0x0012f920, nsIChannel * 0x05f3c030, nsIStreamListener * * 0x0012f974) line 2663 
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x05e840a0, 
const char * 0x0012f920, int 0x00000000, const char * 0x100a66c8 
gCommonEmptyBuffer, nsIChannel * 0x05f3c030, nsIStreamListener * * 0x0012f974, 
int * 0x0012f904) line 103 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x05f3c030, nsISupports * 
0x00000000) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x05e86ee0, 
nsIChannel * 0x05f3c030, nsISupports * 0x00000000) line 233 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x05f3ca60, 
nsIChannel * 0x05f3c030, nsISupports * 0x00000000) line 1122
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x05f8d090, nsIChannel * 0x05f3c030, nsISupports * 0x00000000) line 1186
nsHTTPServerListener::FinishedResponseHeaders() line 1047 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x05f0ee30, 
nsIChannel * 0x05f3c3a4, nsISupports * 0x05f3c030, nsIInputStream * 0x05f08ee0, 
unsigned int 0x00000000, unsigned int 0x00000000) line 427 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x05f94cf0) 
line 400 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x05f922f0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x05f922f0) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00abd510) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x01100084, unsigned int 0x0000c0aa, unsigned int 
0x00000000, long 0x00abd510) line 1054 + 9 bytes
USER32! 77e71820()
00abd510() 

Comment 15

[Phil Schwartau]

correcting Brendan's cc address to "[e-mail]" -

Comment 16

[Brendan Eich [:brendan]]

The last stack (gc_root_marker) after the assertion (in debug builds only) looks
like a topcrash to me -- cc'ing jpatel so he can confirm from talkback data and
add the topcrash keyword.

Cc'ing waterson for generic element script object unrooting fu.

/be

Comment 17

[Chris Waterson]

So brendan and I talked about this. Maybe what's happening is that an HMTL
element is being destroyed, but somehow has failed to unroot it's script object.
We should put an assertion in the nsGenericElement's dtor that ensures its
mScriptObject == nsnull.

I'll take the bug for now and see if I can discover anything...

Comment 18

[Jay Patel [:jay]]

I haven't found any gc_root_marker crashes in the talkback topcrash report data 
lately, but there are a couple of other bugs with the same stack trace as the 
one phil reported today, they are: bug 55445 (new) and bug 55881 (verified 
invalid). Also, is bug 54121 related to this crash?  I will keep an eye out for 
any more info on this crash in the talkback data.  

Comment 19

[Brendan Eich [:brendan]]

jpatel: I pointed out several gc_root_marker-as-second-or-third-frame-down 
talkback stack traces.  The top frame will be js_MarkGCThing or gc_find_flags.  
I therefore believe this bug is a topcrash.  It also looks like a possible dup 
of bug 54121, although that bug lacks a stack to match against.

/be

Comment 20

[sean echevarria]

bug 55881 is invalid because there's no url and are no steps to repro.
As far as bug 54121 goes - I'll remove the patch I applied for it and attach a
stack trace on Friday.

Comment 21

[Brendan Eich [:brendan]]

I claim this is a dup of bug 54121.  Someone prove me wrong!

/be

*** This bug has been marked as a duplicate of 54121 ***

Comment 22

[Jay Patel [:jay]]

Well from what I can tell in the talkback data, if what Brendan claims is true, 
then this bug is in fact a topcrasher because js_MarkGCThing and gc_find_flags 
are still in the topcrash list...but note that the bug for those crashes 53123 
has been fixed, so those crashes are slowly fading away.  From looking at 
the stack for this crash and the one in bug 54121, I would say this bug is a dup 
of 54121.

Comment 23

[Brendan Eich [:brendan]]

I hope js_MarkGCThing and gc_find_flags are echoes of bug 53123-reopen, now
fixed since the end of last month.  But when I analyze more recent talkback data
supplied by jpatel, I found gc_find_flags crashes, called from gc_root_marker 2
frames down.  That's not a signature of 53123 or 53123-reopen.  Recall that in
53123-reopen, the crashing gc_find_flags was called 2 frames down from js_GC.

The difference is that 53123 dealt with bad stack values being marked, where the
bad values came from a bug in a call to OpenDialog, or a similar bug in the JS
engine's JS_PushArgumentsVA API.  This bug, and 54121, deal with dangling roots,
hence the gc_root_marker frame 2 down on the stack.

/be

Comment 24

[shrirang khanzode]

mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"