Closed Bug 1251126 Opened 9 years ago Closed 8 years ago

Intermittent browser_bookmark_popup.js | application crashed [@ nsNavBookmarks::OnDeleteURI(nsIURI*, nsACString_internal const&, unsigned short)] after Assertion failure: history && ((bool)(__builtin_expect(!!(!NS_FAILED_impl(history->GetIdForPage(aURI, &

Categories

(Firefox :: Bookmarks & History, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: philor, Assigned: mak)

References

Details

(Keywords: assertion, intermittent-failure, steps-wanted, Whiteboard: [qx:P-])

Blocks: 1219794
MOZ_ASSERT( history && NS_SUCCEEDED(history->GetIdForPage(aURI, &placeId, placeGuid)) && !placeId, "OnDeleteURI was notified for a page that still exists?" ); Now, supposed history is alive, something is notifying an onDeleteURI for a page that has not been deleted, that's not good. I'll have to audit all onDeleteURI notifiers to ensure we are not doing stupidities.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
there is another possibility, that after we remove a bookmark expiration runs, removes the page, but before we notify uri removal, another bookmark to the same uri is added back...
If bug 1219794 caused this, how important is this to fix? 47 is close to shipping, is this something that could have end-user impact?
Flags: needinfo?(mak77)
It's not critical to fix it, at a maximum some consumer may temporarily think a given uri has been removed (it may disappear from a view). Unfortunately I was unable to reproduce this problem in my tries, and that makes it harder to fix. Could be a race condition as I supposed in comment 2, that makes it even harder to figure, but at the same time it would make it a false positive. Indeed the removal notification would be correct and there would be an addition notification immediately after that.
Flags: needinfo?(mak77)
(note, this is likely due to the fact currently we have 2 bookmarking APIs, one synchronous one asynchronous. We should really find the time to complete deprecation of the old one)
Ok, removing from our QX tracking then.
Whiteboard: [qx:P-]
needs better STR
Assignee: mak77 → nobody
Status: ASSIGNED → NEW
Keywords: steps-wanted
Fixed by bug 1344205.
Assignee: nobody → mak77
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.