Browser hangs intermittently with Flash 6.0

VERIFIED FIXED in mozilla1.2final



16 years ago
16 years ago


(Reporter: Ed Millard, Assigned: av (gone))




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PL2:NA], URL)


(3 attachments)



16 years ago
If you load this URL in Mozilla with the latest Flash 6 Linux Beta it 
intermittently hangs.  Its not clear yet if its the browser, the plugin or a 
combined effort causing the hang.  The stack traces I've looked at are 
generally wandering around in Javascript and the player hasn't done much other 
than load.  
The hang is somewhat intermittent and may involve timing issues on the windows  
mapping and moving around.  Mouse position and motion may also factor in.  
Again not sure if the is a Mozilla or a Flash bug at this point.

Comment 1

16 years ago
This is not likely to be due to JavaScript Engine; reassigning to
Plug-ins, who may be more familiar with this problem; cc'ing self -


Could you attach stack traces via the "Create a New Attachment"
link above? (choose MIME=text/plain). Thanks; that will help us -
Assignee: rogerl → beppe
Component: JavaScript Engine → Plug-ins
QA Contact: pschwartau → shrir
Summary: Browser hangs intermittently → Browser hangs intermittently with latest Flash 6 Linux Beta

Comment 2

16 years ago
Created attachment 104197 [details]
Stack traces of Javascript change

The attachment has 3 stack traces.  The browser is running but it appears to
never make it out of js_Interpret().

Comment 3

16 years ago
Ed: thanks! It's hard to interpret these stack traces, but I'll try to
reproduce the hang myself as well.

By any chance, do you have an audio device running while you're accessing
this site? If so, perhaps this bug is a duplicate of bug 58339:

"Flash plugin (presumably 5.0 r47 - r50 only) hangs Mozilla,
when it's trying to play audio, while audio device is active.
(Reproducible with some [e.g. es1371] sound driver)"

This might also be a duplicate of bug 155423, "Flash Player Freeze",
which was reported with Flash 6 -
Keywords: hang

Comment 4

16 years ago
This is the Flash 6 player.  It doesn't suffer from the Flash 5 audio hang. I 
dont think there is any audio on this page. 

Comment 5

16 years ago
I was able to reproduce the hang using
Shockwave Flash 6.0 r47 (it's released not a beta one), w2k mozilla 20021024
debug build, after couple reloads of test case url.
it looks like
|rv = iim->GetIIDForName(cstring, &iid);|
returns an error for cstring=="PercentLoaded" (which is scriptable method of
flash plug-in I believe) but we are looping here forever:(
ccing jst.

Comment 6

16 years ago
Confirming and resummarizing based on Serge's findings.
Changing OS: Linux ---> All.
Ever confirmed: true
OS: Linux → All
Summary: Browser hangs intermittently with latest Flash 6 Linux Beta → Browser hangs intermittently with Flash 6.0

Comment 7

16 years ago
assigning to av for debug
Assignee: beppe → av
Priority: -- → P2
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2final

Comment 8

16 years ago
Created attachment 104549 [details]
Call stack when it hangs in indefinite loop

Comment 9

16 years ago
After some time debugging this bug I found that it hangs when it cannot get out
of the while loop in |js_Interpret| here: (while (pc < endpc))

I also noticed that when |pc| increments here: (pc += len;)
|len| sometimes is negative, which does not look right to me. Value of the
buffers themselves also looks like we went beyond array boundaries.

If I leave only JS code related to the plugin itself it works fine. 

Reassigning to JavaScript for further look.
Assignee: av → rogerl
Component: Plug-ins → JavaScript Engine
QA Contact: shrir → pschwartau

Comment 10

16 years ago
The line number for the second link to lxr should read #4014.

Comment 11

16 years ago
cc'ing Brendan, Mike, Roger to see if they know why this
infinite loop is occurring -
Assignee: rogerl → khanson
len may be negative, e.g. for a backward branch.

I don't think this is a JS engine bug, yet.  Can you debug more and show some
evidence of an unpoliced infinite loop?  What is the value of script->filename
and script->lineno in the js_Interpret frame from which control never seems to
return? What is the JS script or function starting at that line in that file? 
And does the DOM branch callback not eventually fire?  Pls. confirm that
cx->branchCallback refers to DOMBranchCallback.

Assignee: khanson → av

Comment 13

16 years ago
Compare the Shockwave hang explained at bug 169889 comment #14 -

Comment 14

16 years ago
*** Bug 169889 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
Created attachment 105276 [details] [diff] [review]
patch v1

it appears loading plugin's channel in background is not good idea,
if scriptable plugin is waiting for something to be done with the content in
onload handler we can fall into infinite loop:(

Comment 16

16 years ago
Setting component to Plug-ins, not JS Engine -
Component: JavaScript Engine → Plug-ins
QA Contact: pschwartau → shrir

Comment 17

16 years ago
So, this is a regression. Does it mean that this patch will bring back the bug
about throbber?

Comment 18

16 years ago
I have not seen that, have you?

Comment 19

16 years ago
Comment on attachment 105276 [details] [diff] [review]
patch v1

r=av. Looks like background load has been added in an attempt to fix the
throbber problem. According to serge the problem is now fixed elsewhere, so we
can back it out to fix the regression.
Attachment #105276 - Flags: review+


16 years ago
Attachment #105276 - Flags: superreview?(darin)

Comment 20

16 years ago
Comment on attachment 105276 [details] [diff] [review]
patch v1

sr=darin provided this does not cause bug 172376 to be reopened.
Attachment #105276 - Flags: superreview?(darin) → superreview+

Comment 21

16 years ago
Checked in to the trunk.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021119 (Flash 6 r 47)
still hangs at (the URL I reported in bug 169889 ).

Comment 23

16 years ago
It seems to be busy in a Javascript.  Not sure if its the same bug or not. With 
1.3a the original URL works for me. 
A couple stack traces for on Linux.  It is busy in a Javascript 
#0  0x40f1b18d in NSGetModule ()  
   from /usr/local/mozilla/components/  
#1  0x4019c02b in nsQueryInterface::operator() ()  
   from /usr/local/mozilla/  
#2  0x4019c0f1 in nsCOMPtr_base::assign_from_helper ()  
   from /usr/local/mozilla/  
#3  0x40e238d8 in NSGetModule () from /usr/local/mozilla/components/  
#4  0x40e23d17 in NSGetModule () from /usr/local/mozilla/components/  
#5  0x405a2fe1 in NSGetModule ()  
   from /usr/local/mozilla/components/  
#6  0x40090024 in js_Interpret () from /usr/local/mozilla/  
#7  0x40088fa0 in js_Invoke () from /usr/local/mozilla/  
#8  0x4008919c in js_InternalInvoke () from /usr/local/mozilla/  
#9  0x4006ab1b in JS_CallFunctionValue () from /usr/local/mozilla/  
#0  0x4009ba98 in js_LookupProperty () from /usr/local/mozilla/  
#1  0x4009e33a in js_GetClassPrototype () from /usr/local/mozilla/  
#2  0x4009ace1 in js_NewObject () from /usr/local/mozilla/  
#3  0x400b91d2 in js_StringToObject () from /usr/local/mozilla/  
#4  0x4009e44f in js_ValueToObject () from /usr/local/mozilla/  
#5  0x4009e4ea in js_ValueToNonNullObject ()  
   from /usr/local/mozilla/  
#6  0x4008f6d0 in js_Interpret () from /usr/local/mozilla/  
#7  0x40088fa0 in js_Invoke () from /usr/local/mozilla/  
#8  0x4008919c in js_InternalInvoke () from /usr/local/mozilla/  
#9  0x4006ab1b in JS_CallFunctionValue () from /usr/local/mozilla/  

Comment 24

16 years ago
tested using trunk build on winXP, verify
You need to log in before you can comment on or make changes to this bug.