459411 - Crash in [@ nsNavHistoryResult::OnClearHistory() ] when deleting individual history entry

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Marcia Knous [:marcia]]

Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1.

STR:
1. Open the history sidebar.
2. Select an individual history entry. Invoke the context menu and then select delete.
3. Crash, but have not been able to reproduce as of yet.

A few other details:

JIT was turned on. NoScript and Web of Trust extensions installed.

Breakpad: http://crash-stats.mozilla.com/report/index/602ed730-96f8-11dd-9e08-001321b13766

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Marcia, this stack is truly bizarre!

Clicking down on Delete in the context menu seems to have raised a
modal dialog (a Gecko one).  Then the crash occurred when (with the
modal dialog already displayed) you let go of the mouse button (and a
mouse-up event was sent).

Do you remember seeing anything like that when the crash happened?

Comment 2

[Marcia Knous [:marcia]]

Yes, it seemed as soon as released the mouse button I crashed. I was not able to reproduce during my test session, but I will keep an eye out for it.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

But do you remember seeing a modal dialog pop up when you pressed the mouse button?

Comment 4

[Marcia Knous [:marcia]]

I did not see a modal dialog pop up.  But I hope I am not misremembering the STR - I say that because in my comment I mentioned something about the clear private data dialog :( - if that is the case then I think the stack will make more sense. Let me see if I can find the Litmus test case I was running at the time since it may make more sense.

Comment 5

[Marcia Knous [:marcia]]

The two test cases that I ran right in a row were: https://litmus.mozilla.org/show_test.cgi?id=5939 and https://litmus.mozilla.org/show_test.cgi?id=6099. It might have been that I had the sidebar open and I tried to delete the browsing history by using Clear Private Data, but I cannot say for sure.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Marcia, your stack (from comment #0) tells me the following (I think):

1) You chose something from a menu (by clicking the mouse)
   (-[NativeMenuItemTarget menuItemHit:]).

2) The menu item was invoked (it's action at least began to be
   performed), presumably while the mouse button was still down
   (nsMenuItemX::DoCommand).

3) A modal dialog was displayed (or at least began to be displayed,
   nsXULWindow::ShowModal).  It might have been invisible (behind
   another window, or not yet fully displayed).

4) You let go the mouse button (-[ChildView mouseUp:]).

5) The browser tried to clear all history
   (nsNavHistory::RemoveAllPages), and then crashed.

On the face of it, this doesn't make a whole lot of sense :-)

Choosing "Delete" in your first Litmus test should never result in
nsNavHistory::RemoveAllPages being called (I just tested this in gdb
with the 1.9.1 branch).  But nothing in your second Litmus test
invokes any menu item (results in -[NativeMenuItemTarget menuItemHit:]
being called).

I'm going to have to put this aside until we get more information.

Comment 7

[timeless]

this sounds like the clear private data dialog. which also has a keybinding.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #7)

So it does (the key binding for the Clear Private Data dialog (on OS
X) is cmd-shift-del).

But doing cmd-shift-del doesn't invoke -[NativeMenuItemTarget
menuItemHit:], so our mystery remains unsolved.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

First 20 frames from Marcia's stack trace:

0  	XUL  	nsNavHistoryResult::OnClearHistory  	toolkit/components/places/src/nsNavHistoryResult.cpp:4400
1 	XUL 	nsNavHistoryExpire::ClearHistory 	toolkit/components/places/src/nsNavHistoryExpire.cpp:302
2 	XUL 	nsNavHistory::RemoveAllPages 	toolkit/components/places/src/nsNavHistory.cpp:4010
3 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
4 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2405
5 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1477
6 	libmozjs.dylib 	js_Invoke 	js/src/jsinvoke.cpp:1306
7 	libmozjs.dylib 	js_Interpret 	js/src/jsinterp.cpp:5001
8 	libmozjs.dylib 	js_Invoke 	js/src/jsinvoke.cpp:1324
9 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
10 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:565
11 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93
12 	XUL 	nsXPTCStubBase::Stub3 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:1
13 	XUL 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1080
14 	XUL 	nsEventListenerManager::HandleEvent 	content/events/src/nsEventListenerManager.cpp:1185
15 	XUL 	nsEventTargetChainItem::HandleEvent 	content/events/src/nsEventDispatcher.cpp:211
16 	XUL 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventDispatcher.cpp:269
17 	XUL 	nsEventDispatcher::Dispatch 	content/events/src/nsEventDispatcher.cpp:479
18 	XUL 	PresShell::HandleDOMEventWithTarget 	layout/base/nsPresShell.cpp:5943
19 	XUL 	nsButtonBoxFrame::DoMouseClick 	layout/xul/base/src/nsButtonBoxFrame.cpp:160
20 	XUL 	nsButtonBoxFrame::HandleEvent 	layout/xul/base/src/nsButtonBoxFrame.cpp:130 

There are a lot of crashes reported for Firefox 3.0.3 with the same top frames. Also seems to happen on Windows.

http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&query=nsNavHistoryResult%3A%3AOnClearHistory()&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsNavHistoryResult%3A%3AOnClearHistory()

Stacks on Windows are a bit shorter:

0  	xul.dll  	nsNavHistoryResult::OnClearHistory  	 mozilla/toolkit/components/places/src/nsNavHistoryResult.cpp:4396
1 	xul.dll 	nsNavHistoryExpire::ClearHistory 	mozilla/toolkit/components/places/src/nsNavHistoryExpire.cpp:303
2 	xul.dll 	nsNavHistory::RemoveAllPages 	mozilla/toolkit/components/places/src/nsNavHistory.cpp:3996
3 	xul.dll 	NS_InvokeByIndex_P 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
4 	xul.dll 	XPCWrappedNative::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dietrich, somehow related to bug 426275?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #10)
> Dietrich, somehow related to bug 426275?

Marco, could you elaborate?

Comment 12

[Marco Bonardo [:mak]]

are there still reports of this crash on current 3.5? could simply be another case related to bad cycle collecting (bug 487040)

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Having the limited search functionality on Socorro I wasn't able to find any crash report of this type in the last weeks, but that doesn't mean anything. It's hard to check for a longer period.

Comment 14

[Carlos Alén Silva]

This happened to me in 3.5, but the crash reporter didn't show up :(

Also, deleting a bookmark folder with many bookmards (rss feeds) froze Firefox for a few minutes, then everything was fine again.

Comment 15

[Marco Bonardo [:mak]]

how can you tell it was this bug? did you see the crash signature with onClearHistory in it? did you get a debugger stack trace? or is that just a guess ecause the crash happened after a clear history?

Comment 16

[Carlos Alén Silva]

(In reply to comment #15)

Just a guess, sorry. It happened several times in different situations, but all with a delete history event in common. So I guessed that deleting history leads to crash. It might be another different issue.

Comment 17

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 18

[Marco Bonardo [:mak]]

I'm going to resolve this, I think it was just a bad CC case, most likely the same as bug 426275, currently I don't see any crash reported for this signature.