Closed
Bug 39703
Opened 24 years ago
Closed 24 years ago
Crashing releasing a null pointer
Categories
(Core Graveyard :: RDF, defect, P4)
Tracking
(Not tracked)
RESOLVED
FIXED
M17
People
(Reporter: slogan, Assigned: harishd)
Details
(Keywords: crash, Whiteboard: [NEED INFO])
Maybe the NS_RELEASE should be an NS_RELEASE_IF ?? XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x04596f20, int 0x00000001) line 556 + 12 bytes CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x046e5600, unsigned int 0x00000000, int 0x00000001, nsIParser * 0x04798f20, nsIContentSink * 0x04596f20) line 290 + 20 bytes nsParser::DidBuildModel(unsigned int 0x00000000) line 986 + 60 bytes nsParser::ResumeParse(int 0x00000001, int 0x00000001) line 1466 nsParser::OnStopRequest(nsParser * const 0x04798f28, nsIChannel * 0x044e06e0, nsISupports * 0x00000000, unsigned int 0x804b0002, const unsigned short * 0x00000000) line 1920 + 19 bytes nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x044e5900, nsIChannel * 0x044e06e0, nsISupports * 0x00000000, unsigned int 0x804b0002, const unsigned short * 0x00000000) line 204 nsFileChannel::OnStopRequest(nsFileChannel * const 0x044e06e4, nsIChannel * 0x044e3630, nsISupports * 0x00000000, unsigned int 0x804b0002, const unsigned short * 0x00000000) line 625 + 45 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x046e5350) line 307 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x046e50e0) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x046e50e0) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0430db30) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x04dc0322, unsigned int 0x0000c10b, unsigned int 0x00000000, long 0x0430db30) line 1030 + 9 bytes USER32! 77e71268() 0430db30()
This happened when I dismissed an IM pref panel.
Comment 2•24 years ago
|
||
Sounds like something a bit weirder is going on...I'll take a look.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Checking with tester to see if this is still happening with latest builds.
QA Contact: tever → scalkins
Whiteboard: [NEED INFO]
Comment 4•24 years ago
|
||
Any news on this one? I'm getting a crash at startup time on OpenVMS, and the footprint is similar. This is with code pulled around last Friday (5/19). Starting mozilla-bin... Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End ProfileManager : GetProfileDir ProfileManager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End WEBSHELL+ = 1 WEBSHELL+ = 2 %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000 0000, PC=0000000000C3F458, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine LIBRDF NSXULCONTENTSINK DidBuildModel LIBRAPTORHTMLPARS NSWELLFORMEDDTD DidBuildModel LIBRAPTORHTMLPARS NSPARSER ResumeParse LIBRAPTORHTMLPARS NSPARSER OnDataAvailable LIBNECKO NSFILECHANNEL OnDataAvailable LIBNECKO NSASYNCSTREAMLISTENER HandleEvent LIBNECKO NSASYNCSTREAMLISTENER HandlePLEvent LIBXPCOM PLEVENT PL_HandleEvent LIBXPCOM PLEVENT PL_ProcessPendingEvents LIBXPCOM NSEVENTQUEUE ProcessPendingEvents LIBWIDGET_GTK NSAPPSHELL our_gdk_io_invoke LIBGLIB GIOUNIX g_io_unix_dispatch LIBGLIB GMAIN g_main_dispatch LIBGLIB GMAIN g_main_iterate LIBGLIB GMAIN g_main_run LIBGTK GTKMAIN gtk_main LIBWIDGET_GTK NSAPPSHELL Run MOZILLA-BIN NSAPPRUNNER main1 MOZILLA-BIN NSAPPRUNNER main MOZILLA-BIN NSAPPRUNNER __MAIN MOZILLA-BIN PTHREAD$RTL PTHREAD$RTL XML Error in file 'chrome://navigator/content/navigator.xul', Line Number: 38, Col Number: 0, Description: error in processing external entity reference Source Line: %navigatorDTD; The accvio message says that we are trying to access address 0 for read access.
Comment 5•24 years ago
|
||
I am not seeing this crash, but here is what appears in navigator.xul around those lines: <!DOCTYPE window [ <!ENTITY % brandDTD SYSTEM "chrome://global/locale/brand.dtd" > %brandDTD; <!ENTITY % navigatorDTD SYSTEM "chrome://navigator/locale/navigator.dtd" > %navigatorDTD; ]> I'm not familiar enough with XML to know what this means, or what an error *about* this means. With respect to the original stack trace, I might as well change http://lxr.mozilla.org/mozilla/source/rdf/content/src/nsXULContentSink.cpp#556 to do NS_IF_RELEASE() just to be defensive. That said, I'm not sure how we'd ever *get* here if the content sink didn't have a parser. harishd, rickg: has the parser changed recently such that the content sink might get a "SetParser(nsnull)" call before getting a "DidBuildModel()" call?
Comment 6•24 years ago
|
||
Forget the crash on OpenVMS, that was my fault. I had some "merge conflict" text left in my navigator.dtd file that I let slip through. Sorry!! Mozilla comes up now.
This could be mine.
Assignee: waterson → harishd
Status: ASSIGNED → NEW
Comment 9•24 years ago
|
||
colin: We should *never* crash, whatever nonsense we have in our data files. Could you file a new bug on that issue?
Comment 10•24 years ago
|
||
I filed bug #40452 for the crash the occurs when the dtd file contains badness.
Comment 11•24 years ago
|
||
FYI, I changed the NS_RELEASE() to NS_IF_RELEASE() in nsXULContentSink::DidBuildModel().
Assignee | ||
Comment 12•24 years ago
|
||
Thanx, Chris. I'll investigate the problem. Could be due to the new path through which XML/XUL errors are propagated to the sink.
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•24 years ago
|
||
After waterson's fix we shouldn't crash anymore. Removing crash & nsbeta2. Syd, let me know what you think about it.
Assignee | ||
Comment 16•24 years ago
|
||
Does this problem still exist?
Comment 17•24 years ago
|
||
Not since I made DidBuildModel() do an NS_IF_RELEASE()....
Assignee | ||
Comment 18•24 years ago
|
||
Lowering the priority..becase it shouldn't crash anymore ( after waterson's fix ).
Priority: P1 → P4
Assignee | ||
Comment 19•24 years ago
|
||
I presume that this is not a problme bug anymore. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 20•24 years ago
|
||
Verifying branch (Used case of dismissal of IM prefs panel to verify) Win32 2000-10-25-09MN6 setting vtrunk
Keywords: vtrunk
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•