Closed Bug 165393 Opened 22 years ago Closed 22 years ago

crash when flash plug-in enabled [@ nsBlockFrame::GetTopBlockChild]

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jacekchmiel, Assigned: karnaze)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Mozilla crashes completely when entering http://mp3.wp.pl due to flash plug-in issue. Removing flash plug-in solves the problem. Reproducible: Always Steps to Reproduce: 1. open http://mp3.wp.pl 2. browser crashes 3. remove flash plugin DLL 4. restart mozilla 5. open http://mp3.wp.pl 6. it's ok now Actual Results: browser crashes Expected Results: should not crash Identified this to be flash plug-in issue (the newest Macromedia Flash plug-in 6). Reproduced on 4 diferrent machines - some running Windows 2000 Pro En, some Windows XP Pro en. Official Mozilla 1.1 build.
*** Bug 165391 has been marked as a duplicate of this bug. ***
No crash here. NT4 SP6a German Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 Flash Player 6,0,47,0
WFM 2002082608/trunk/W2K Jacek: Can you please use a talkback enabled build? After Mozilla crashed the TalkBack will runned and it will automatically submit the crash. Than run "mozilla.org/bin/components/talkback.exe" manually and post the talkback ID of that crash in this bug.
I always use talkback builds - I've sent that crash report many times. Those reports were sent to you (incidend IDs: TB9985385Q, TB9985404M, TB9985365X).
thanks for TB reports top part of stack trace from TB9985385Q: nsBlockFrame::GetTopBlockChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3061] nsBlockFrame::ReflowBlockFrame [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3459] nsBlockFrame::ReflowLine [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2499] nsBlockFrame::ReflowDirtyLines [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2277] nsBlockFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 951] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] nsTableCellFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableCellFrame.cpp, line 946] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] nsTableRowFrame::IR_TargetIsChild [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1300] nsTableRowFrame::IncrementalReflow [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1191] nsTableRowFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1453] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] nsTableRowGroupFrame::IR_TargetIsChild [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 1630] nsTableRowGroupFrame::IncrementalReflow [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 1298] nsTableRowGroupFrame::Reflow [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 1207] nsContainerFrame::ReflowChild [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830] ... other reports show almost the same stacks, and the problem is in |nsTableFrame::Reflow| and there is no plugin code at all.
Summary: crash when flash plug-in enabled → crash when flash plug-in enabled [nsBlockFrame::GetTopBlockChild]
You're right but why removing flash plug-in helps? Strange behavior...
Reproduced error with Mozilla 1.0.1 and Netscape 7.0 - this huhe bug exists in both 1.0 and 1.1 Mozilla builds...
>Strange behavior probably javascript content is smart enough to recognize that there is no plugin for this client and it actually serves different content for such clients
Keywords: stackwanted
OK - whatever it is - it should be fixed. Checked today's 1.0 branch build - still crashes. Critical bug still remains unconfirmed...
could not reproduce the crasher on trunk 0831 with flash installed. reporter, does the advertisement banner change for you or is it the same all the time ?
Build 20020903. Different behavior: without flash mp3.wp.pl works OK, with flash plug-in enabled -> Mozilla freezes, memory usage raises very quickly to maximum available memory and ... crash (no more virtual memory available for allocation) (Windows XP EN, 512MB RAM)
Jacek: what version of Flash do you have installed?
Macromedia Flash Player 6: http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&P5_Language=English No problems with the plugin on the other pages - the only problem is that mentioned page crashes with 100% probability. I test it everyday both on my PC at work and my pc at home, both running Windows XP and the same flash plugin.
http://mp3.wp.pl WFM: w2k, Gecko/20020904, Flash 6.0 r47 Shrir could you try this, please?
wfm :(
did you try XP?
I've asked Terri to test this using 4.x and Flash6 as well as with NSCP build on a winXP machine. She has tested it on the trunk build from today and it does not crash. Updates coming in regard to 4.x (to verify it isn't the plug-in itself).
WFM using win XP trunk build 2002090408 (with default plugin and with plugin installed from http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&P5_Language=English) No crash either with plugin or without
No crash using win XP official Mozilla 1.1 build either
Checked once again on another "clean" PC: w2k server sp3 en, clean mozilla install (no mozilla before), Mozilla 1.1 official + flash plugin 6 = mp3.wp.pl crashes browser
Additional info: browser crashes only when .SWF file is already in the cache (disk cache). Disabling disk cache (size 0KB) seems to solve the problem. Another way to reproduce the bug (with disk cache enable): enter mp3.wp.pl, wait for the page to load, enter www.wp.pl, click BACK button - crash!
Is this related to bug 136927?
hmm, it could be related, but I cannot make it crash, the page loading is slow for me, and therefore the controls flow of my client is probably different than for users from .pl domain, and I cannot get into stage when crash occurs:(
Jacek, did you submit any TB reports for latest crashes?
Jacek: did you try grabbing the data in the log file?
Attached file Crash log (deleted) —
Mozilla intercepted plugin error (message box) this time. (mp3.wp.pl of course)
TB numbers are: 10414409H 10414401Z 10257517H 19255557Y 10040202K 9956033W 9954479K 9951116M Many still in the queue...
Reproduced bug with the lastest Mozilla build 2002090511. TB reports IDs: 10459797W 10459831K 10460713E
Attached file from tb report 10460713 (deleted) —
all tb reports have stack traces similar to this one, there is no plugins code at all, this is |nsTableFrame::Reflow| problem
Ok, anyway I help as much as I can. Disabling flash plugin really helps but it may be just because it changes the page controls reflow (I agree with comment #8). This bug may indicate something much more serious than simple Macromedia plugin bug.
I am resigning this to karnaze
Assignee: beppe → karnaze
this is a wfm on 1021 trunk.
Jacek, do you still crash using latest nightly build or latest 1.2 ? http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.2
Works fine, bug may be closed, I will reopen if needed. I'm unable to reproduce crash using the latest build. Althought overall performance of latest 1.2 build is disappointing...
Marking WFM as per reporter comments. Jacek, the perf issues are tracked through bug 103712.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Summary: crash when flash plug-in enabled [nsBlockFrame::GetTopBlockChild] → crash when flash plug-in enabled [@ nsBlockFrame::GetTopBlockChild]
Crash Signature: [@ nsBlockFrame::GetTopBlockChild]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: