624944 - Crashes in [@ nsNavHistory::CanAddURI(nsIURI*, int*) ] and [@ nsNavHistory::AddVisit(nsIURI*, long long, nsIURI*, int, int, long long, long long*) ]

Status: RESOLVED WORKSFORME

(Toolkit :: Places, defect)

Description

[Joe Drew (not getting mail)]

My wife recently had several crashes in a row at the above signatures. It happened about every two minutes, three times, then stopped. It's not clear why or what happened to start/stop it.

bp-5dfed10d-1441-4334-a99f-227202110109
bp-10dcad62-3a45-47f8-b7ca-3326e2110111
bp-ac6ff8a6-6bad-441e-9812-dd6272110111

Looking through crash-stats, there are several similar crashes.

Comment 1

[Marco Bonardo [:mak]]

some crash is reported in 4.0 beta too, the underlying stack is different though. 

http://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsNavHistory%3A%3ACanAddURI%28nsIURI*%2C%20int*%29

Comment 2

[Marco Bonardo [:mak]]

fwiw, correlations are insteresting in this
100% (54/54) vs.   1% (1271/174449) {340c2bbc-ce74-4362-90b5-7c26312808ef} (Mozilla Labs - Weave Sync, https://addons.mozilla.org/addon/10868)

Comment 3

[Marco Bonardo [:mak]]

Looking at recent crash-stats data, this crash doesn't look that interesting on 4.0.  4.0b10 has one 1 report, but the stack points to a nonsense point, 4.0b9 has 14 reports but the stack as well doesn't seem that usual. On 4.0 it's a crash on startup though.

On 3.6.x we hit this more frequently and not on startup, it usually comes through LazyMessages, we removed them on 4.0.x so the ratio can make sense.
I can exclude aURI from being null though, since we would bail out earlier, so either aURI points to a broken address, or the uri object has a broken spec buffer.  In either cases sounds like something is wrong in the ownership and the uri object is corrupt.
A couple interesting facts: on 1.9.2 we use much more nsIURI->Clone than on central, I tried to check if there could be a broken Clone implementation, but I've only found bug 559496 that seems to be Mac only, our crashes appear on other OSs though.

Comment 4

[(no longer active)]

This is not a topcrash on trunk, so I'm not sure why it's a blocker.

Comment 5

[Marco Bonardo [:mak]]

it was a blocker for investigation since some signature was appearing on trunk... it doesn't need to block based on comment 3, since I nominated it, I'm clearing the request as well.

Comment 6

[Jerry Krinock]

I think I've discovered the same problem.  If I recall correctly, I was getting crashes before I enclosed the following code in a try/catch block.  It occurs when I invoke history service's addVisit function in a JavaScript XPCOM component in a Firefox extension, running in Firefox 4.0b11.

var historyService = Components.classes["@mozilla.org/browser/nav-history-service;1"].getService(Components.interfaces.nsINavHistoryService) ;
var ioService = Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService);

var uri = ioService.newURI("http://apple.com", null, null) ;

historyService.addVisit(
                                         uri, 
                                         100000,
                                         1261440000000000,
                                         historyService.TRANSITION_BOOKMARK,
                                         false, 
                                         0
                                         ) ;

According to the documentation for addVisit, argument 2 is supposed to be a long long, as you can see I am providing.  But I get an exception:

[Exception... "Could not convert JavaScript argument arg 2 [nsINavHistoryService.addVisit]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///Users/jk/Library/Application%20Support/Firefox/Profiles/dev/extensions/[e-mail]/components/MyXPCOM.js :: <TOP_LEVEL> :: line 511"  data: no]

Comment 7

[Shawn Wilsher :sdwilsh]

(In reply to comment #6)
> historyService.addVisit(
>                                          uri, 
>                                          100000,
>                                          1261440000000000,
>                                          historyService.TRANSITION_BOOKMARK,
>                                          false, 
>                                          0
>                                          ) ;
Are you sure this is the code that was being problematic?  It doesn't do this for me.

Comment 8

[Marco Bonardo [:mak]]

I'm starting thinking this 3.6.x crash could have similar reasons as bug 634796, Sync spins the events loop in our observers and this crash is for sure due to lazy messages (that current FF4.0 doesn't have anymore).
Looking at correlations:

100% (45/45) vs.   1% (781/107892) {340c2bbc-ce74-4362-90b5-7c26312808ef} (Mozilla Labs - Weave Sync, https://addons.mozilla.org/addon/10868)

Comment 9

[Marco Bonardo [:mak]]

I can only find nonsense stacks with this signature, I think this bug doesn't exist anymore