Closed Bug 624944 Opened 10 years ago Closed 8 years ago

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

Categories

(Toolkit :: Places, defect)

1.9.2 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
status2.0 --- unaffected

People

(Reporter: joe, Unassigned)

Details

(Keywords: crash)

Crash Data

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.
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
Severity: normal → critical
blocking2.0: --- → ?
blocking2.0: ? → betaN+
Whiteboard: [softblocker]
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)
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.
This is not a topcrash on trunk, so I'm not sure why it's a blocker.
blocking2.0: betaN+ → ?
Whiteboard: [softblocker]
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.
blocking2.0: ? → ---
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/firefoxextension@mycompany.com/components/MyXPCOM.js :: <TOP_LEVEL> :: line 511"  data: no]
(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.
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)
Crash Signature: [@ nsNavHistory::CanAddURI(nsIURI*, int*) ] [@ nsNavHistory::AddVisit(nsIURI*, long long, nsIURI*, int, int, long long, long long*) ]
I can only find nonsense stacks with this signature, I think this bug doesn't exist anymore
Status: NEW → RESOLVED
Crash Signature: [@ nsNavHistory::CanAddURI(nsIURI*, int*) ] [@ nsNavHistory::AddVisit(nsIURI*, long long, nsIURI*, int, int, long long, long long*) ] → [@ nsNavHistory::CanAddURI(nsIURI*, int*) ] [@ nsNavHistory::AddVisit(nsIURI*, long long, nsIURI*, int, int, long long, long long*) ]
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.