537839 - Failure & abort in test_browserGlue_prefs.js, with xpcshell return code: -1073741819 and "ASSERTION: SetItemDateAdded failed"

Status: RESOLVED WORKSFORME

(Toolkit :: Places, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: snippet of full log

Failure as highlighted by shortlog looks like this:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262636005.1262644024.4641.gz
WINNT 5.2 mozilla-central debug test everythingelse on 2010/01/04 12:13:25
s: win32-slave13
{
TEST-UNEXPECTED-FAIL | e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-everythingelse\build\xpcshell\tests\test_browser_places\unit\test_browserGlue_prefs.js | test failed (with xpcshell return code: -1073741819), see following log:
TEST-UNEXPECTED-FAIL | e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-everythingelse\build\xpcshell\tests\test_browser_places\unit\test_browserGlue_prefs.js | application crashed (minidump found)
}

The assertion that fails just before the abort is:
###!!! ASSERTION: SetItemDateAdded failed: 'NS_SUCCEEDED(rv)', file e:/builds/moz2_slave/mozilla-central-win32-debug/build/browser/components/places/src/nsPlacesImportExportService.cpp, line 954

The context lines in the shortlog aren't very helpful, so I'm attaching the chunk of the full log that corresponds to this test (test_browserGlue_prefs.js)

Comment 1

[Marco Bonardo [:mak]]

interesting, insertBookmark does not fail, but the next call to setItemDateAdded fails, when it get the item type, through getItemType.

Comment 2

[Marco Bonardo [:mak]]

I'm unsure what's up here, insertBookmark does not fail (it would assert), that should ensure that we get an itemId (the last inserted one).  Since last itemId is phisically selected from the table through a query and not got through an sqlite api, that row must exist.
Just a bit later setItemDateAdded bails out on a not existant itemId (with NS_ERROR_INVALID_ARG).  This can happen either if itemId < 1 or if the row for that itemid does not exist.  I can exclude the itemId < 1 case, since it would warn inside getItemType (NS_ENSURE_MIN would NS_WARNING).
So we select from the table, and we don't find a row with that itemId, it has disappeared, but we selected that row just some ms before.
Flush component does not touch moz_bookmarks table, maintenance component is not even in scope since it starts in delayed startup. So i can't see anything that could delete a bookmark in the middle.

Comment 3

[Marco Bonardo [:mak]]

test was cleaned up in central and lot of code changed, I assume this is WFM now.