Closed Bug 157157 Opened 23 years ago Closed 23 years ago

crashes seemingly at random times [@ BitsToMap], often in QuickDraw [eg. @GetQDGlobalsBlack]

Categories

(Camino Graveyard :: Plug-ins, defect)

defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: winnie, Assigned: sfraser_bugs)

References

()

Details

(Keywords: crash, regression)

Crash Data

Attachments

(7 files, 4 obsolete files)

07-08-16 build OS 10.1.5 1. Go to eweek.com 2. Click on an article from the home page. 3. App crashes. This bug was originally reported to me by dbradley. I was able to repro it once, but I don't seem to be able to repro it anymore.
Attached file crash log (obsolete) —
What I was seeing was intermittant crashes at various sites. Somemtimes it would only take a couple of links to crash, other times it would take several links before it would crash. I've crashed at www.cnn.com, www.netscape.com, www.eweek.com, and a few others so far. I'm not seeing anything in common among these, other than they have frames and a fair number of images. Also the browser once returned with a page, stating an Invalid HTTP request had been submitted. I have Netscape 7.0 on this same box and it works just fine, so I don't think it's environment related. I'm new to the Mac, so I'm not sure how to get a crash log, if someone will send me instructions I'll collect a few and submit a couple.
WorksForMe using Chimera/20020708. Winnie or David, can you also reproduce this crash using Mozilla? I have ads blocked at the site in question. Could one of the ads be causing the crashes? Is that plug-in stuff I see in the stack? David, see [http://www.mozilla.org/mailnews/osxinfo.html], particularly "Enabling Crash Reporter in OS X *10.1*".
Severity: normal → critical
Keywords: crash
plugin listener crash, ->bnesse
Assignee: saari → bnesse
Blocks: 147975
*** Bug 157425 has been marked as a duplicate of this bug. ***
*** Bug 149382 has been marked as a duplicate of this bug. ***
Crashed for me too, stack only slightly different: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000854 <-----------Different Thread 0: #0 0x734faf4c in QDIsPortBuffered <-----------Different #1 0x735081a0 in QDPlatformGlobalToLocal Everything is still basically the same.
I finally got a Mozilla build on my Mac that I can debug and I can't get it to crash. This was a trunk build from a few days ago. I'll play some more. It might be a debug/release issue. I'll try a Mozilla release build next.
Component: General → Plug-ins
Attachment #91122 - Attachment mime type: text/plain → application/rtf
*** Bug 160989 has been marked as a duplicate of this bug. ***
*** Bug 168023 has been marked as a duplicate of this bug. ***
Attached patch PatchSplinter Review
The plugin code is improperly bypassing the nsInputStreamTee object (a hybrid read/write stream) when it fails to retrieve a cached local file output stream. The nsInputStreamTee object already handles the case of an empty output object, and should not be circumvented in this way. Always creating the nsInputStreamTee object and allowing it to "do the right thing" eliminates this crash.
Comment on attachment 99561 [details] [diff] [review] Patch r=beard
Attachment #99561 - Flags: review+
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 168747 has been marked as a duplicate of this bug. ***
*** Bug 171294 has been marked as a duplicate of this bug. ***
Brian, is that patch applicable to the Mozilla trunk at all? Bug 171370's stack looks somewhat similar.
I don't think you will find any crossover in this patch. All of the code that this patch changes no longer exists on the trunk.
*** Bug 171989 has been marked as a duplicate of this bug. ***
People are apparently still experiencing this crash with post-20020920 nightly builds. See bug 171989.
Reopening per comment 19.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 172381 has been marked as a duplicate of this bug. ***
*** Bug 172507 has been marked as a duplicate of this bug. ***
*** Bug 172738 has been marked as a duplicate of this bug. ***
*** Bug 173047 has been marked as a duplicate of this bug. ***
*** Bug 172986 has been marked as a duplicate of this bug. ***
*** Bug 172999 has been marked as a duplicate of this bug. ***
*** Bug 173189 has been marked as a duplicate of this bug. ***
Summary: Crash when clicking on article link from eweek.com home page → crashes seemingly at random times [@ BitsToMap]
*** Bug 173288 has been marked as a duplicate of this bug. ***
*** Bug 173313 has been marked as a duplicate of this bug. ***
*** Bug 173510 has been marked as a duplicate of this bug. ***
*** Bug 173902 has been marked as a duplicate of this bug. ***
*** Bug 173788 has been marked as a duplicate of this bug. ***
*** Bug 173845 has been marked as a duplicate of this bug. ***
Attached file Mac OS X Crash Log (obsolete) —
Last 2 builds of Chimera crash (Unexpected Quit...) *Every Single Time* I launch. No idea why, I'm hoping someone who can read a crash log can tell me what's going on. (email: djfox@nosi.com if you have the answer)
Comment on attachment 102648 [details] Mac OS X Crash Log Marking the stack trace obsolete, because it doesn't belong in this bug. The js_AtomizeString issue is over in bug 173311.
Attachment #102648 - Attachment is obsolete: true
*** Bug 173193 has been marked as a duplicate of this bug. ***
*** Bug 174114 has been marked as a duplicate of this bug. ***
*** Bug 174195 has been marked as a duplicate of this bug. ***
*** Bug 174190 has been marked as a duplicate of this bug. ***
Attached file Reduced test case from eweek.com (obsolete) —
Test case contains a simple iframe. Iframe source will load a flash based ad. Scroll down to bottom of page and press reload toolbar icon. A crash results.
Attachment #91122 - Attachment is obsolete: true
*** Bug 174171 has been marked as a duplicate of this bug. ***
*** Bug 174269 has been marked as a duplicate of this bug. ***
*** Bug 174433 has been marked as a duplicate of this bug. ***
*** Bug 171894 has been marked as a duplicate of this bug. ***
Attached file Better test case
Test case contains a iframe which references a .swf file. Load test case and scroll to bottom of page. Press the reload toolbar icon. The crash occurs.
Attachment #102766 - Attachment is obsolete: true
Changing QA contact and owner
Assignee: bnesse → peterl
Status: REOPENED → NEW
QA Contact: winnie → petersen
people were bitching about this just today in the newsgroup.
Severity: critical → blocker
Target Milestone: --- → Chimera0.6
In the testcase, it crashes when dispatching a null event (timer-generated) to the plugin, just after the reload. It could be that the plugin hasn't been drawn yet, so the QD port isn't set up. It would be useful to see a testcase for a page that loads a plugin that is initially off-screen (i.e. has a plugin at the bottom of a long page). Does that crash too?
Chimera crashes upon loading this test case
(That testcase didn't crash Chimera/2002101504 on 10.1.5 for me, after loading it then reloading it ten times.)
This seems to be a iframe (with contains a plugin) only issue. If I substitute the iframe with a EMBED element (using the same .swf source), the crash doesn't occur.
Using the 2002-10-17-04 build, I can reproduce this crash under 10.1.5 by loading the 1000px DIV test case.
Summary: crashes seemingly at random times [@ BitsToMap] → crashes seemingly at random times [@ BitsToMap], often in QuickDraw [QD in trace]
*** Bug 173131 has been marked as a duplicate of this bug. ***
*** Bug 175280 has been marked as a duplicate of this bug. ***
In the testcase, the flash has to be in an <iframe> for it to crash. Putting it in an <embed> in the same document doesn't crash. So this probably has something to do with wiget/view parenting.
*** Bug 175443 has been marked as a duplicate of this bug. ***
*** Bug 175504 has been marked as a duplicate of this bug. ***
*** Bug 175957 has been marked as a duplicate of this bug. ***
*** Bug 176250 has been marked as a duplicate of this bug. ***
is it helpful for developers to receive more stack traces when users get crashes on this bug, or is there enough info available at this point to identify the root cause?
At http://www.nytimes.com, crashes very regularly, mainly (but not always) when opening another page from the same site in a new tabbed window
*** Bug 176332 has been marked as a duplicate of this bug. ***
*** Bug 176426 has been marked as a duplicate of this bug. ***
I'm seeing the nytimes.com problem as well. Crashes every single time for me, not in BitsToMap. Mozilla has no problems with the page.
Got the GetQDGlobalsBlack crash on the Google News page (http://news.google.com/). Can't reproduce it though.
Also got the GetQDGlobalsBlack crash immediately after submitting the last comment :)
Summary: crashes seemingly at random times [@ BitsToMap], often in QuickDraw [QD in trace] → crashes seemingly at random times [@ BitsToMap], often in QuickDraw [eg. @GetQDGlobalsBlack]
this is a cross platform problem, attachment 10324 [details] crashes on all platforms when reloaded. On Linux it says "Bad Window" and it's crashing in a similar spot on Win32 so I suspect the iframe's window has been destoryed too early.
Status: NEW → ASSIGNED
Keywords: regression
OS: MacOS X → All
Product: Chimera → Browser
Hardware: Macintosh → All
Summary: crashes seemingly at random times [@ BitsToMap], often in QuickDraw [eg. @GetQDGlobalsBlack] → plugin inside IFRAME crashes on page teardown: bad window
Target Milestone: Chimera0.6 → mozilla1.2final
Version: unspecified → other
I don't think this is an XP problem. I can't reproduce it in a CFM mozilla build, and it doesn't always happen in Chimera. The crash is in QuickDraw and, in the chimera case, the QuickDraw port that the plugin is using will not have gone away, because that port is attached to the top-level window, not the plugin's widget. I think the real reason for this crash is that when ns4xPluginStreamListener::OnDataAvailable() is called, we have no guarantee that we've set up a QuickDraw port for the plugin correctly. Other plugin entry-points use FixUpPluginWindow() etc. to set the port up, but no such preparation is done for this OnDataAvailable() call (and it's hard to do, because we can't easily get at the widget).
Another thing; the crash happens on page load, not page teardown. So it can't be that the window has been released too early.
Summary: plugin inside IFRAME crashes on page teardown: bad window → plugin inside IFRAME crashes on page teardown: bad window (QuickDraw, QD)
Hm....I'm only crashing on reloading the testcase in Chimera. Maybe I need to try harder and these are two seperate bugs. I'm not crashing in debug Mach-O Seamonkey build with the patch to get plugins working either. On Chimera, I get various stacks, some of them already go through the timer and FixUpPluginWindow() and crash in ClipRect/RectRgn/SetRectRgn. So on Win32, we weren't actually crashing but rather asserting in a debug build on |VERIFY(::DestroyWindow(mWnd))| in nsWindow.cpp. The problem there seems to be that the parent window of the plugin (the IFRAME in this case) is being destoryed before the child. This patch allows the nsFrameFrame to destory its children before its frame. I just made this patch in 5 minutes so I'm not sure what else it breaks but it does seem to stop the crash on Linux. I still need to get an opt build of Chimera to try it there. One other problem I noticed was that the plugin for the next page was being created before the previous one was destoryed. I think the previous content viewer needs to be destoryed before the plugin is about to be created. This could also be causing some problems as I noticed the plugin sometimes didn't re-appear on reload when running with this patch on Linux.
This bug started to show up often and seriously in Chimera only after 0.5 (that is, 0.5 is still OK). It seems that Chimera is still Mozilla 1.0.1 based and hasn't been synced with the trunk. (Right?) I think it would be rather stange if this was a cross-platform thing common with the trunk Linux builds.
*** Bug 176671 has been marked as a duplicate of this bug. ***
*** Bug 176736 has been marked as a duplicate of this bug. ***
with 2002.10.25.14, i cannot get the tests here to crash (so far) on either 10.1.5 or 10.2.1.
Test cases work for me in 2002102604 on 10.2.1. I've also seen comments on the Chimera board that the NYTimes site isn't crashing anymore.
okay, I've been chasing down bug 173938 by mistake which seems to be a regression from bug 52334 and was not checked into the 1.0 branch. This bug on yesterday's Chimera build seems to be fixed, probably due to Simon's uber plugin patch in bug 176649. I'm marking this FIXED, if it still happens, please reopen.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Product: Browser → Chimera
Resolution: --- → FIXED
Summary: plugin inside IFRAME crashes on page teardown: bad window (QuickDraw, QD) → crashes seemingly at random times [@ BitsToMap], often in QuickDraw [eg. @GetQDGlobalsBlack]
Target Milestone: mozilla1.2final → ---
Version: other → unspecified
Verified in the 2002-10-28-04 NB under 10.2.1.
Status: RESOLVED → VERIFIED
Attached file Crash Log (obsolete) —
Hate to break it to you... but using the latest nightly just got a crash QDIsPortBuffered at www.digidesign.com... (loading flash at top of the page). It is temperamental as I haven't got it again (only been trying for about 2 mins though) This is symptomatic of the original problem for this bug (before it got narrowed down). Perhaps it needs to be filed as a seperate bug...
Comment on attachment 104451 [details] Crash Log Sorry - my bad... somehow old dmg got remounted and ended up using an old nightly... oops ;-)
Attachment #104451 - Attachment is obsolete: true
Attached file Stack crawl
This is a stack crawl from trying to access http://espn.go.com/mlb/playoffs2002/s/2002/1028/1452046.html with the latest nightly (2002102917). [From Douglas Beach in <public.mozdev.chimera/A14A0EBA-EADE-11D6-BA79-003065BDF5B8@mchsi.com> on news.mozdev.org]
I get the same crash in 2002102904. Should this be a new bug?
I get the crash as well (under both 10.1.5 and 10.2.1) using the url specified in comment #82. Tested with 2002-10-30-04 NB. Simon or Peter L, should we reopen or create a new bug ?
Originally reported at chimera@mozdev.org mailing list, I got another site reported that reproduces this crash when switching between tabs: Step 1: Load a page (any page will do) Step 2: Create a new tab Step 3: Go to http://www.gpf-comics.com/ or another Keenspot comic page Step 4: Go back to the first tab. Step 5: Go back to the Keenspot tab. I can reproduce under 10.1.5 and 10.2.1 using the 2002-10-30-04 NB.
Reopening based on testcase.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Further reduced steps from comment #87: 1) Open http://www.gpf-comics.com/ 2) Press command- E which creates page source tab 3) Click on first tab containing gdf site. A crash should occur.
Mine
Assignee: peterl → sfraser
Status: REOPENED → NEW
Looking at the ESPN crash, I really think that we're seeing a Flash bug. It looks like Flash is calling GetQDGlobalsBlack() with a nil param, which will crash. The signature is Pattern* GetQDGlobalsBlack(Pattern * black); When the crash occurs, the port is good (it's the window port), but R3 is nil (which is where the parameter should be). A test app that calls GetQDGlobalsBlack(nil); crashes in exactly the same place.
Interesting. But if so, why doesn't it crash when I go to that URL in IE? (Talkback for that crash was TB10288Z.)
Using the 2002-10-27-04 build, I can't reproduce the 'gpf-comic' crash. Regression since then?
The ESPN crash above is a bug in the Flash player. Updating to the latest beta version of Flash (6.0r60) fixes it. That's available from here: http://www.macromedia.com/software/flashplayer/special/beta/
Status: NEW → ASSIGNED
After upgrading to Flash 6.0r60 I cannot reproduce either the ESPN crash or the gpf-comics crash.
Installed this same flash plugin (6.0r60) under 10.2.1. I can no longer reproduce problem using comments 82-87.
using 2002103104 and flash 6.0 r60 I am still crashing when following any of the links on the left side of ESPN.com
I'm not able to reproduce the same problem in comment #95. Loaded espn.com and navigated the links on left side of page (NFL - scores, NBA -scores, NHL -scores, etc). Tested under 10.2.1 using 2002-10-31-04 (Flash 6.0r60).
I recant comment #95. Apparently one needs to log-out to get the flash plug-in to reload? A friend and I both repeatedly crashed espn.com after updating the flash player last night. This morning we are both fine. all the links 0 crashing (current nightly + 10.2.x).
*** Bug 177739 has been marked as a duplicate of this bug. ***
*** Bug 178843 has been marked as a duplicate of this bug. ***
*** Bug 171989 has been marked as a duplicate of this bug. ***
*** Bug 180054 has been marked as a duplicate of this bug. ***
*** Bug 183218 has been marked as a duplicate of this bug. ***
I'm going to mark this fixed. The main cause, Shockwave 6.0r47, is superseded by 6.0r60 which fixes the crash. Other causes of QuickDraw crashes I hope have been fixed by the fix for bug 182384.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Yep, this problem is no longer occuring with the latest plugin. Verified with the 2002-12-04-04 NB and Flash 6.0 r61 installed.
Status: RESOLVED → VERIFIED
No longer blocks: 147975
For anyone continuing to experience this bug, Flash 6.0r67 has been publicly released. http://www.macromedia.com/downloads/
*** Bug 187968 has been marked as a duplicate of this bug. ***
*** Bug 188257 has been marked as a duplicate of this bug. ***
*** Bug 196789 has been marked as a duplicate of this bug. ***
*** Bug 205020 has been marked as a duplicate of this bug. ***
Crash Signature: [@ BitsToMap]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: