Status

()

Core
XUL
--
critical
RESOLVED DUPLICATE of bug 218031
15 years ago
7 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

({crash, topcrash})

Trunk
x86
All
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
IsChromeURI 39ca4415

   Stack Trace:

   IsChromeURI [c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp
line 1501]
   nsChromeRegistry::RefreshWindow
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp line
   1621]
   nsChromeRegistry::RefreshWindow
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp line
   1518]
   nsChromeRegistry::RefreshSkins
[c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp line 1468]
   XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line
   102]
   EventHandler [c:/builds/seamonkey/mozilla/xpcom/proxy/src/nsProxyEvent.cpp
line 564]
   PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c line 672]
   PL_ProcessPendingEvents [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c
line 610]
   _md_EventReceiverProc [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c
line 1413]
   USER32.dll + 0x4455 (0x77d44455)
   USER32.dll + 0x95d5 (0x77d495d5)
   nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 484]
   main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1306]
   main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1672]
   WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1694]
   WinMainCRTStartup()
   kernel32.dll + 0x214c7 (0x77e814c7)

   Source File :
   c:/builds/seamonkey/mozilla/rdf/chrome/src/nsChromeRegistry.cpp line no: 1501

   Build: 2003082704 CrashDate: 2003-08-28 UptimeMinutes: 6 Total: 6
   OS: Windows NT 5.1 build 2600
   URL:
   Comment:
   BBID: 23129634

1505 alecf          1.247 nsresult
nsChromeRegistry::RefreshWindow(nsIDOMWindowInternal* aWindow)
1554                                rv = sheet->GetURL(*getter_AddRefs(uri));
1555 warren         1.140           if (NS_FAILED(rv)) return rv;
1556 hyatt          1.117
1557 hyatt          1.227           if (IsChromeURI(uri)) {
^ doesn't null check
...
1609                          rv = sheet->GetURL(*getter_AddRefs(uri));
1610 warren         1.140     if (NS_FAILED(rv)) return rv;
1611 hyatt          1.117
1612 bzbarsky       1.255     if (IsChromeURI(uri)) {
1613                            // Reload the sheet.
^ doesn't null check

1802 CSSStyleSheetImpl::GetURL(nsIURI*& aURL) const
1803 {
1804   NS_IF_ADDREF(aURL = (mInner ? mInner->mURL.get() : nsnull));
1805   return NS_OK;
1806 }
^ returns NS_OK and outs null

553 HTMLCSSStyleSheetImpl::GetURL(nsIURI*& aURL) const
554 {
555   NS_IF_ADDREF(mURL);
556   aURL = mURL;
557   return NS_OK;
558 }
^ returns NS_OK and outs null

1497 hyatt          1.117 static PRBool IsChromeURI(nsIURI* aURI)
1498                      {
1499 gagan          1.176     PRBool isChrome=PR_FALSE;
1500 valeski        1.185     if (NS_SUCCEEDED(aURI->SchemeIs("chrome",
&isChrome)) && isChrome)
^ derefs null
(Assignee)

Comment 1

15 years ago
.
Assignee: hyatt → timeless
(Assignee)

Comment 2

15 years ago
Created attachment 130577 [details] [diff] [review]
wallpaper

This patch is designed not to change nearby lines so blame remains unaltered.
but it should deal with the crash. and when bz gets back from vacation he can
do something about it.
(Assignee)

Updated

15 years ago
Attachment #130577 - Flags: superreview?(darin)
Attachment #130577 - Flags: review?(tingley)

Comment 3

15 years ago
timeless: can you give examples of how and when someone might hit this crash in
the real world?  is there a site where we end up hitting this crash?
Um... how are we getting sheets with a null URL?  That's not acceptable, since 
it leads to immediate correctness issues (eg resolution of relative URLs in the 
CSS would be broken).

Did you do anything special other than changing themes?
(Assignee)

Comment 5

15 years ago
sorry. this is based on talkback crash data. it was a huge blip that happened
today. i don't believe there were urls in it.
Status: NEW → ASSIGNED

Comment 6

15 years ago
I'm a little sketchy on wallpapering this so quick when we still don't
really have a description of when it happens, especially since the
correctness issues that result may just cause the bug to get refiled
as some other (seemingly unrelated) behavior.
On the other hand, if it's in 1.5b...
Fwiw, preserving the blame lines doesn't seem like a /huge/ priority,
since the actual problem presumably lies elsewhere.
Anyways, I'd like to give it a couple days, to see if we can flush
out some sort of steps to reproduce.
If it's just something that we want to wallpaper in 1.5, we can also do that on
the branch.

I checked the places that create stylesheets in the code (except composer, since
I can't find that code at the moment) and they all seem to do the right thing
(init the sheet with a non-null URI, that is).   There are OOM conditions that
could lead to sheets without uris, however...  could that have been an issue here?

Comment 8

15 years ago
> There are OOM conditions that could lead to sheets without uris, however...  
> could that have been an issue here?

From the comments in talkback, it looked like people were installing or
uninstalled incompatible (old) themes.
Hmm...  That should still not lead to broken sheets, since the provider should
just be dropped in the chrome registry and the sheets for that skin should never
be loaded.

ccing some people who may know something about how the chrome registry is
supposed to work; I wish hyatt read bugmail.

Comment 10

15 years ago
I tried installing/uninstalling various versions of pinball (a common culprit in
talkback comments).  Mozilla 1.5b installed but refused to use it, and it
uninstalled fine.

It showed up in talkback for Linux as _Z11IsChromeURIP6nsIURI()
OS: Windows 2000 → All

Comment 11

15 years ago
@see also bug 218031.
Please retest.  This should now be fixed.

Comment 13

15 years ago
Ugh, this never had steps to reproduce.  We may just have to keep an eye on
talkback data and see if the signature drops off.
(Assignee)

Comment 14

15 years ago
Current report:
Crash data range: 2003-10-02 to 2003-10-06
Build ID range: 2003100105 to 2003100405
Fix went in at "2003-10-06 07:27".  But there have been no Windows builds since
2003100405 which explains the data....
(Assignee)

Comment 16

14 years ago
Simple Crash Analysis Trunk Builds - all
 This report was generated on 10/30/03 and contains 10 days of data. 
 Total blackboxes in this sample:      461
 Total unique users:      208
 MTBF For these builds is estimated at 7.784671 hours,
 based on 461 reports and 3588.733333 hours of user testing

Hits for "IsChromeURI" in report: 0.

*** This bug has been marked as a duplicate of 218031 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Assignee)

Updated

14 years ago
Attachment #130577 - Flags: superreview?(darin)
Attachment #130577 - Flags: review?(tingley)
(Assignee)

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
Crash Signature: [@ IsChromeURI]
You need to log in before you can comment on or make changes to this bug.