Closed Bug 196094 Opened 21 years ago Closed 21 years ago

Trunk crash [@ RDFServiceImpl::GetResource]

Categories

(Core Graveyard :: RDF, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jay, Assigned: bzbarsky)

References

Details

(Keywords: crash, topcrash+)

Crash Data

Attachments

(1 file)

Looks like this crash first appeared with 2/25 MozillaTrunk builds.  There have
been a few here and there since then.  I don't see any crashes with Mozilla 1.3
Beta...so this seems to be a new regression:

RDFServiceImpl::GetResource   9 
BBID range: 17573876 - 17730612
Min/Max Seconds since last crash: 2 - 62312
Min/Max Runtime: 3 - 62312
Crash data range: 2003-02-27 to 2003-03-04
Build ID range: 2003022516 to 2003030308

Stack Trace: 

	 RDFServiceImpl::GetResource
[c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFService.cpp  line 1025]
	 nsBookmarksService::CreateBookmark
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 2758]
	 nsBookmarksService::CreateBookmarkInContainer
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 2823]
	 nsBookmarksService::ParseFavoritesFolder
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 3324]
	 nsBookmarksService::ParseFavoritesFolder
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 3301]
	 nsBookmarksService::ImportSystemBookmarks
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 3367]
	 nsBookmarksService::HandleSystemBookmarks
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 3383]
	 nsBookmarksService::HasAssertion
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 3978]
	 CompositeDataSourceImpl::HasAssertion
[c:/builds/seamonkey/mozilla/rdf/base/src/nsCompositeDataSource.cpp  line 1143]
	 CompositeDataSourceImpl::OnAssert
[c:/builds/seamonkey/mozilla/rdf/base/src/nsCompositeDataSource.cpp  line 1469]
	 nsBookmarksService::OnAssert
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 5595]
	 InMemoryDataSource::Assert
[c:/builds/seamonkey/mozilla/rdf/base/src/nsInMemoryDataSource.cpp  line 1392]
	 nsBookmarksService::LoadBookmarks
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 4958]
	 nsBookmarksService::ReadBookmarks
[c:/builds/seamonkey/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp
 line 4789]
	 XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp 
line 102]
	 XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp  line 2025]
	 XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp 
line 1293]
	 js_Invoke	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c  line 845]
	 js_Interpret	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c  line 2812]
	 js_Invoke	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c  line 861]
	 js_InternalInvoke	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c  line 936]
	 JS_CallFunctionValue	[c:/builds/seamonkey/mozilla/js/src/jsapi.c  line 3434]
	 nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp  line 1043]
	 GlobalWindowImpl::RunTimeout
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 4751]
	 GlobalWindowImpl::TimerCallback
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 5107]
	 nsTimerImpl::Fire	[c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp 
line 383]
	 nsAppShell::Run	[c:/builds/seamonkey/mozilla/widget/src/windows/nsAppShell.cpp
 line 176]
	 nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp  line 480]
	 main1	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1289]
	 main	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1639]
	 WinMain	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1660]
	 WinMainCRTStartup()
	 KERNEL32.dll + 0x2847c (0x77ea847c)
 
 	Source File : c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFService.cpp line :
1025
     (17730612)	Comments: I was trying to opening Mozilla 1.3b; don't know why
the Netscape Qulaity Feedback Agent got involved.
     (17708367)	Comments: opened program
     (17642992)	Comments: Mozilla crashes at launch
     (17642698)	Comments: Mozilla crashes on launch. I even have uninstalled 
deleted the programdata catalog  run Norton Windoctor to clean up the mess and
reinstalled. Don't help
     (17573915)	URL: http://www.caplex.no
     (17573915)	Comments: Mozilla crashes when loading
     (17573876)	Comments: hitting refresh button because address would not show
up in the address bar also i could not type anything in there
*** Bug 196093 has been marked as a duplicate of this bug. ***
This is a regression from bug 190020.  The code says:

1021 cbiesinger 1.96     nsACString::const_iterator p, end;
1022                     aURI.BeginReading(p);
1023                     aURI.EndReading(end);
1024                     while (IsLegalSchemeCharacter(*p) && p != end)
1025 waterson   1.42         ++p;

Now consider what happens when you hit p == end.  You'll end up dereferencing p
and calling IsLegalSchemeCharacter() on null (of you are lucky) or garbage (if
you are unlucky).

The test _should_ read:

while (p != end && IsLegalSchemeCharacter(*p))
  ++p;
Keywords: qawanted
sounds right to me. I'm amazed it caused a crash though. It almost sounds like
the nsDependentString is being set up wrong.
bz: oooops, you are right. r=biesi for that change.
Making topcrash+ since it looks like we have some idea of what's going on here.
 Still need to set priority and target milestone though...and a QA contact might
come in handy! ;-)
Keywords: topcrashtopcrash+
Attachment #116834 - Flags: superreview?(alecf)
Attachment #116834 - Flags: review?(cbiesinger)
I just checked this in to get it into today's build.
Assignee: rjc → bzbarsky
Oh.  Um, fixed I guess.  jpatel, could you verify based on talkback data results?
QA Contact: jpatel
.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
(oops sorry meant to mark that fixed after assigning to you, boris!)
Attachment #116834 - Flags: review?(cbiesinger) → review+
Current Talkback data shows we haven't seen a crash since 3/4 Trunk builds. 
I'll wait a few more days to see if any crashes show up.  If not, I'll mark this
verified.
oh! What do you bet this was fixed by the assertion fixes (the sizeof() junk)
No bet.  ;)

The patch you guys landed is still the right one for readablility and
correctness, imo.
A really good point. After that patch, the url has the right, long enough
content. so that likely means it includes the : in the url, which is no legal
scheme character (I think), which causes the loop to abort before the end is
reached.
Attachment #116834 - Flags: superreview?(alecf) → superreview+
According to talkback this - or something similar - crashes again since yesterday.
...and not only on rare occasions...
Yeah, it seems like another crash started on 3/12 on the Trunk.  Looking at the
stack, it looks like a different crash.  I'll go ahead and log a new bug.  
Logged bug 198467 for new crashes at RDFServiceImpl::GetResource.  Please take a
look and cc yourself if you can help.  Thanks.
Disregard my last comment, bug 197237 was already logged and a fix was just
checked in on 3/19.

I'm going to verify this bug fixed.
Status: RESOLVED → VERIFIED
Crash Signature: [@ RDFServiceImpl::GetResource]
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: