Closed Bug 58252 Opened 24 years ago Closed 24 years ago

Crash [@ RDFServiceImpl::GetDataSource]

Categories

(Core Graveyard :: RDF, defect, P3)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hjtoi-bugzilla, Assigned: waterson)

Details

(Keywords: crash, topcrash, Whiteboard: [fixinhand,r=rjc,a=alecf][rtm++][FIXED ON TRUNK])

Crash Data

Attachments

(2 files)

This is a topcrash reported by Talkback. There are 14 instances according to the Talkback sidebar. One Linux, other various Windows versions. The crash seems to happen mostly in startup. I cannot reproduce this. It looks like the crash happens because for some reason we are handed either a null or garbage pointer as the out param pointer and when we assign to it we crash. If we are handed a null pointer it would be easy to prevent a crash here. Right now the method is not checking if the out param != 0, which is the Right Thing To Do(TM). This is more like band-aid than real fix, we should also find out WHY someone is passing in a null pointer (if this is the cause of the crash). Here is the stack trace: RDFServiceImpl::GetDataSource [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFService.cpp line 1136] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp line 139] nsXPCWrappedNativeClass::CallWrappedMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeclass.cpp line 915] WrappedNative_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp line 223] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 822] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 2621] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 994] JS_ExecuteScript [d:\builds\seamonkey\mozilla\js\src\jsapi.c line 3044] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp line 726] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp line 5488] nsXULDocument::OnStreamComplete [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp line 5438] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp line 123] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp line 703] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line 302] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 581] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 517] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1051] KERNEL32.DLL + 0x248f7 (0xbff848f7) 0x0068820e 0x00058f64
Keywords: crash, topcrash
Whiteboard: [fixinhand?]
I'm 99% sure that the crash is on the addref at line 1135, not the assign. XPConnect is almost certainly *not* giving us bad return slots, or we'd be crashing all over. (Furthermore, this "off-by-one" in Win32 crash reports is fairly typical; the PC is set to the instruction immediately after the branch through a garbage vtable.) Anyway, see bug 57764, where I tried to fix a known problem. I'll leave this bug open, because I haven't looked at builds post 2000-10-24, when this fix was checked in.
jband, you think you're giving me a bad pointer for an retval? See http://www.mozilla.org/projects/seamonkey/reports/ns6analysis.html#RDFServiceImpl::GetDataSource
Yeah, looking at http://cyclone/reports/incidenttemplate.cfm?setvar=DeveloperDeveloperTabSet:Code%20Around%20the%20PC&bbid=19403673#DeveloperMachineState you can tell that it's blowing up on the virtual call to AddRef(). So, as I suspected, something's not being removed from the datasource table. Bugger.
Whiteboard: [fixinhand?]
rjc: I found two more datasources that fail to match calls to RegisterDataSource() with calls to UnregisterDataSource(), nsLocalStore.cpp and nsInternetSearchService.cpp. Could you r= the changes? I made it so that the RDF service could support weak references (and modernized some of the macro-munging in that ancient file); scc, would you mind sanity checking that code?
r=rjc for the UnregisterDataSource() changes
hooray, thanks for fixing this - sr=alecf
I am nominating this for RTM because this is a topcrash. I am also adding rtm+ on the status whisteboard because this has been properly reviewed and super reviewed. Hopefully we could squeeze this one in...
Keywords: rtm
Whiteboard: [fixinhand,r=rjc,a=alecf][rtm+]
This bug is in candidate limbo. We will reconsider this fix once we have a candidate in hand, but we can't take this fix before then. Please check into the trunk ASAP.
Fixed on trunk.
Whiteboard: [fixinhand,r=rjc,a=alecf][rtm+] → [fixinhand,r=rjc,a=alecf][rtm+][FIXED ON TRUNK]
rtm++, please checkin ASAP so we can build today.
Whiteboard: [fixinhand,r=rjc,a=alecf][rtm+][FIXED ON TRUNK] → [fixinhand,r=rjc,a=alecf][rtm++][FIXED ON TRUNK]
Fix checked in on branch.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Between 2000102600 and today , there have been 9 incidents per Talkback of this crash. This fix was done on 11/1. I looked all incidents where Call Stack Signature contains RDFServiceImpl::GetDataSource. Since 11/1 at 4:26pm, all reported incidients with this stack track are from PR3. Prior to that, there were many incidents from folks using the latest builds. I think we can mark this verified.
Status: RESOLVED → VERIFIED
Crash Signature: [@ RDFServiceImpl::GetDataSource]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: