Closed Bug 62968 Opened 24 years ago Closed 14 years ago

null table and success condition for morkStore->GetTable

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: danm.moz, Assigned: Bienvenu)

References

Details

Attachments

(4 files)

I'm crashing after clearing my profile in some new code Alec checked in on the 12th. Patch to fix attached. Of course, I may have picked the wrong thing to do when count == 0, but it made sense to me at the time. diff -u -r1.63 nsGlobalHistory.cpp --- nsGlobalHistory.cpp 2000/12/12 21:07:30 1.63 +++ nsGlobalHistory.cpp 2000/12/15 19:51:06 @@ -1782,15 +1782,18 @@ // a lot of deleted rows. The file size is the size when we opened the db, // and we really want it to be the size after we've written out the file, // but I think this is a good enough approximation. - PRInt64 numRows; - PRInt64 bytesPerRow; - PRInt64 desiredAvgRowSize; - - LL_UI2L(numRows, count); - LL_DIV(bytesPerRow, mFileSizeOnDisk, numRows); - LL_I2L(desiredAvgRowSize, 400); - if (LL_CMP(bytesPerRow, >, desiredAvgRowSize)) - commitType = kCompressCommit; + if (count > 0) + { + PRInt64 numRows; + PRInt64 bytesPerRow; + PRInt64 desiredAvgRowSize; + + LL_UI2L(numRows, count); + LL_DIV(bytesPerRow, mFileSizeOnDisk, numRows); + LL_I2L(desiredAvgRowSize, 400); + if (LL_CMP(bytesPerRow, >, desiredAvgRowSize)) + commitType = kCompressCommit; + } } } }
this is the correct thing, thanks dan. feel free to check this in, sr=alecf
Now I'm getting another crash. Now I've had to put the whole chunk in an if (mTable) clause. Is that a good thing, too, or is that just scary? At the time, the containing nsGlobalHistory object hasn't been deleted; its refcount is 4 and it looks otherwise healthy.
ok, THAT is bad - mTable should generally not be null (in fact, the factory constructor for nsGlobalHistory should not succeed if it can't create mTable) . .. let me see if I can figure out how that would even happen, but check in your first patch..
first patch is checked in. can't call the crash fixed yet, though, so leaving the bug open.
*** Bug 63210 has been marked as a duplicate of this bug. ***
yeah, I just somehow got into a state where I crash on exit every time also (mTable is null, same place). not sure what I did. here's the stack, as if we didn't know already... nsGlobalHistory::Commit(nsGlobalHistory::eCommitType kLargeCommit) line 1864 + 23 bytes nsGlobalHistory::Flush(nsGlobalHistory * const 0x026abb74) line 1591 XPTC_InvokeByIndex(nsISupports * 0x026abb74, unsigned int 6, unsigned int 0, nsXPTCVariant * 0x007bda60) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x026af5a0, nsXPCWrappedNative * 0x012fbf00, const XPCNativeMemberDescriptor * 0x012f8e30, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x02deef10, long * 0x007bdc48) line 920 + 42 bytes WrappedNative_CallMethod(JSContext * 0x026af5a0, JSObject * 0x00e2f7a8, unsigned int 0, long * 0x02deef10, long * 0x007bdc48) line 228 + 34 bytes js_Invoke(JSContext * 0x026af5a0, unsigned int 0, unsigned int 0) line 784 + 23 bytes js_Interpret(JSContext * 0x026af5a0, long * 0x007be994) line 2607 + 15 bytes js_Invoke(JSContext * 0x026af5a0, unsigned int 1, unsigned int 2) line 801 + 13 bytes js_InternalInvoke(JSContext * 0x026af5a0, JSObject * 0x00e309c8, long 15079336, unsigned int 0, unsigned int 1, long * 0x007beb2c, long * 0x007beabc) line 873 + 20 bytes JS_CallFunctionValue(JSContext * 0x026af5a0, JSObject * 0x00e309c8, long 15079336, unsigned int 1, long * 0x007beb2c, long * 0x007beabc) line 3264 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x026af750, void * 0x00e309c8, void * 0x00e617a8, unsigned int 1, void * 0x007beb2c, int * 0x007beb28, int 0) line 928 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x012f8264) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x0278c450, nsIDOMEvent * 0x012f8264, nsIDOMEventTarget * 0x026af980, unsigned int 2, unsigned int 7) line 843 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x02777aa0, nsEvent * 0x007bf0bc, nsIDOMEvent * * 0x007bf08c, nsIDOMEventTarget * 0x026af980, unsigned int 7, nsEventStatus * 0x007bf100) line 1420 + 39 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x026af970, nsIPresContext * 0x02777aa0, nsEvent * 0x007bf0bc, nsIDOMEvent * * 0x007bf08c, unsigned int 1, nsEventStatus * 0x007bf100) line 565 nsWebShell::FireUnloadEvent(nsWebShell * const 0x026ae23c) line 261 + 42 bytes nsWebShell::Destroy(nsWebShell * const 0x026ae134) line 1441 + 21 bytes nsXULWindow::Destroy(nsXULWindow * const 0x026ae784) line 330 nsWebShellWindow::Destroy(nsWebShellWindow * const 0x026ae784) line 1782 + 9 bytes nsWebShellWindow::Close(nsWebShellWindow * const 0x026ae7e4) line 347 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x007bf348) line 426 nsWindow::DispatchEvent(nsWindow * const 0x026ae594, nsGUIEvent * 0x007bf348, nsEventStatus & nsEventStatus_eIgnore) line 687 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x007bf348) line 708 nsWindow::DispatchStandardEvent(unsigned int 101) line 728 + 15 bytes nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 0x007bf6b0) line 2841 nsWindow::WindowProc(HWND__ * 0x00000c84, unsigned int 16, unsigned int 0, long 0) line 943 + 27 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 007b8736()
Severity: major → critical
Keywords: crash
Attached file my history.dat (deleted) —
I cleared my history fairly recently, but that doesn't seem to be the only thing that causes this. I assert when opening the (blank) global history window: ###!!! ASSERTION: null ptr: 'aTable != nsnull', file C:\mozilla\xpfe\components\ history\src\nsGlobalHistory.cpp, line 201 with stack: nsMdbTableEnumerator::Init(nsIMdbEnv * 0x02703858, nsIMdbTable * 0x00000000) line 201 + 32 bytes nsGlobalHistory::GetTargets(nsGlobalHistory * const 0x027047e0, nsIRDFResource * 0x02702b90, nsIRDFResource * 0x02703210, int 1, nsISimpleEnumerator * * 0x03798b48) line 1244 + 25 bytes CompositeAssertionEnumeratorImpl::GetEnumerator(nsIRDFDataSource * 0x027047e0, nsISimpleEnumerator * * 0x03798b48) line 496 + 37 bytes CompositeEnumeratorImpl::HasMoreElements(CompositeEnumeratorImpl * const 0x03798b38, int * 0x007be50c) line 226 + 22 bytes RDFContainerMemberTestNode::FilterInstantiations(InstantiationSet & {...}, void * 0x007be6ec) line 3559 + 42 bytes TestNode::Propogate(const InstantiationSet & {...}, void * 0x007be6ec) line 870 + 19 bytes TestNode::Propogate(const InstantiationSet & {...}, void * 0x007be6ec) line 876 + 30 bytes RootNode::Propogate(const InstantiationSet & {...}, void * 0x007be6ec) line 595 + 30 bytes nsXULTemplateBuilder::CreateContainerContents(nsIContent * 0x03791150, nsIRDFResource * 0x02702b90, int 0, nsIContent * * 0x00000000, int * 0x00000000) line 6256 + 48 bytes nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsIContent * 0x03791150, nsIContent * * 0x00000000, int * 0x00000000) line 6178 + 34 bytes nsXULTemplateBuilder::CreateContents(nsXULTemplateBuilder * const 0x037971b4, nsIContent * 0x03791150) line 4314 + 19 bytes nsXULDocument::CreateContents(nsXULDocument * const 0x033d48d4, nsIContent * 0x03791150) line 2115 + 16 bytes nsXULElement::EnsureContentsGenerated() line 3729 + 27 bytes nsXULElement::ChildCount(const nsXULElement * const 0x03791150, int & 8120684) line 2349 + 8 bytes nsCSSFrameConstructor::ProcessChildren(nsIPresShell * 0x033d6410, nsIPresContext * 0x033d5330, nsFrameConstructorState & {...}, nsIContent * 0x03791150, nsIFrame * 0x02b7728c, int 0, nsFrameItems & {...}, int 0, nsTableCreator * 0x00000000) line 11483 nsCSSFrameConstructor::ConstructXULFrame(nsIPresShell * 0x033d6410, nsIPresContext * 0x033d5330, nsFrameConstructorState & {...}, nsIContent * 0x03791150, nsIFrame * 0x02b908f4, nsIAtom * 0x01a3c190, int 6, nsIStyleContext * 0x037fd4d0, nsFrameItems & {...}, int 0, int & 0) line 6232 + 44 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x033d6410, nsIPresContext * 0x033d5330, nsFrameConstructorState & {...}, nsIContent * 0x03791150, nsIFrame * 0x02b908f4, nsIAtom * 0x01a3c190, int 6, nsIStyleContext * 0x037fd4d0, nsFrameItems & {...}, int 0) line 7596 + 60 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x033d6410, nsIPresContext * 0x033d5330, nsFrameConstructorState & {...}, nsIContent * 0x03791150, nsIFrame * 0x02b908f4, nsFrameItems & {...}) line 7500 + 56 bytes nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x033d6790, nsIPresContext * 0x033d5330, nsIContent * 0x033e7b80, nsIContent * 0x03791150, int 6, nsILayoutHistoryState * 0x00000000) line 8983 + 46 bytes StyleSetImpl::ContentInserted(StyleSetImpl * const 0x033d6850, nsIPresContext * 0x033d5330, nsIContent * 0x033e7b80, nsIContent * 0x03791150, int 6) line 1178 PresShell::ContentInserted(PresShell * const 0x033d6418, nsIDocument * 0x033d48d0, nsIContent * 0x033e7b80, nsIContent * 0x03791150, int 6) line 4297 + 50 bytes nsXBLBindingRequest::DocumentLoaded(nsIDocument * 0x037e7b10) line 175 nsXBLStreamListener::Load(nsIDOMEvent * 0x037ff564) line 398 nsEventListenerManager::HandleEvent(nsIPresContext * 0x00000000, nsEvent * 0x007bf66c, nsIDOMEvent * * 0x007bf63c, nsIDOMEventTarget * 0x037e7b3c, unsigned int 7, nsEventStatus * 0x007bf6b0) line 1379 + 23 bytes nsDocument::HandleDOMEvent(nsDocument * const 0x037e7b10, nsIPresContext * 0x00000000, nsEvent * 0x007bf66c, nsIDOMEvent * * 0x007bf63c, unsigned int 1, nsEventStatus * 0x007bf6b0) line 3106 nsXMLDocument::EndLoad(nsXMLDocument * const 0x037e7b10) line 678 nsXMLContentSink::DidBuildModel(nsXMLContentSink * const 0x037e8b30, int 1) line 291 CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x037e6490, unsigned int 0, int 1, nsIParser * 0x037e71e0, nsIContentSink * 0x037e8b30) line 293 + 20 bytes nsParser::DidBuildModel(unsigned int 0) line 1418 + 60 bytes nsParser::ResumeParse(int 1, int 1) line 1937 nsParser::OnStopRequest(nsParser * const 0x037e71e8, nsIChannel * 0x037e7770, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 2370 + 19 bytes nsXBLStreamListener::OnStopRequest(nsXBLStreamListener * const 0x037e88e0, nsIChannel * 0x037e7770, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 299 + 42 bytes nsJARChannel::OnStopRequest(nsJARChannel * const 0x037e7774, nsIChannel * 0x037eef10, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 701 + 53 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x037e60b0) line 300 + 46 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x037e60c0) line 92 + 12 bytes PL_HandleEvent(PLEvent * 0x037e60c0) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00fb7b10) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000003b0, unsigned int 60365, unsigned int 0, long 16481040) line 1054 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 007b8a22()
*** Bug 62931 has been marked as a duplicate of this bug. ***
Attached file history.dat - by Request (deleted) —
Crashes at nsGlobalHistory::Commit are currently #3 on the talkback lists. See ftp://ftp.mozilla.org/pub/data/crash-data/ for details. These crashes have been becoming gradually more common in builds over the past week (#30 in 12-18 builds to #3 in 12-25 builds).
Keywords: topcrash
Temporary Fix: Rename the history.dat file. A new one will be created and there will be no more crashes. Tested Successfully in about the 20th Build
must fix for beta1...
Keywords: nsbeta1
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
Okay, I can consistently crash by: (1) Deleting my profile. (2) Starting Mozilla (with homepage set to mozilla.org) (3) Opening the Preferences window. (4) Going to Navigator > History. (5) Clicking `Clear History' twice. (6) Closing the Preferences window. (7) Exiting Mozilla. (8) Starting Navigator. Closing windows in the new instance of Mozilla will crash.
Attached patch null-pointer check (deleted) — Splinter Review
this doesn't fix the problem, but it prevents the crash... I'll check this in, and leave this bug open so I can figure out why mTable becomes null
if I'm gonna do a half-assed fix, I might as well do it right. This fix actually deletes history.dat when mTable is null (by returning a failure condition from OpenExistingFile()) and warns you on the console when it happens. I kept the other null pointer check around anyway, and also changed one of the other failure to NS_ERROR_NOT_INITIALIZED to match the other places where we check these results
merge the mStore and mTable checks and r=blake ...
done! thanks. Now reassigning to bienvenu to fix the basic mork problem, and removing all keywords (since it doesn't crash anymore, doesn't need to be fixed for beta, etc)
Assignee: alecf → bienvenu
Status: ASSIGNED → NEW
Keywords: crash, nsbeta1, topcrash
Summary: crash flushing history → null table and success condition for morkStore->GetTable
what's the basic mork problem? is it that mork databases can get corrupted (e.g., if you run two netscape/mozilla's against the same profile)? If so, that's covered by several other bugs. Or is there some specific mork problem hidden somewhere in this bug description that I'm not seeing?
well, the problem is that GetTable() is returning a null table, but with a success condition, which means basically that the database is corrupted in some wierd way such that you can open it, etc, but you can't retrieve any tables out of it. Maybe that is as designed, but it seems like we should be getting an error condition, or there should be some earlier failure when the file is read in. (i.e. because you can open the file just fine) it's not a big deal, but I figure we should keep the bug open about it until it's resolved once and for all
ah, I see. But this doesn't warrant a mozilla .8 milestone anymore. Changing target to unspecified.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.8 → ---
adding mostfreq keyword. following the chain there are at least 5 duplicates of this.
Keywords: mostfreq
If this is going to be mostfreq then it needs a description that humans can understand :-) Also, to avoid the mostfreq table growing to gargantuan proportions, we tend to use 10 dupes as the min. limit... If anyone can summarise what you do to get this problem in one line, please re-mark this mostfreq :-) Gerv
Keywords: mostfreq
*** Bug 68380 has been marked as a duplicate of this bug. ***
this no longer crashes, right, so I'm lowering priority and severity.
Severity: critical → normal
Priority: P1 → P3
QA Contact: claudius → stephend
Component: History: Session → Document Navigation
QA Contact: stephend → docshell
Now that Firefox3 is saving history using SQLite (Bug 242207) it is time to close this bug.
resolving invalid
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: