monotone - Bugs: bug #17801, crash when running...
You are not allowed to post comments on this tracker with your current authentication level.
bug #17801: crash when running 'regenerate_rosters' on NetBSD src and pkgsrc repositories.
Submitter: | Daniel Carosone <uep> | ||
Submitted: | Tue 19 Sep 2006 06:11:39 AM UTC | ||
Votes: | 5 | ||
Category: | None | Severity: | 4 - Important |
Item Group: | crash | Status: | Remind |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | ||
mtn version --full: | 0.30
|
Fri 22 Sep 2006 12:39:24 PM UTC, comment #3: |
Daniel Carosone <uep>![]() |
Tue 19 Sep 2006 09:27:03 PM UTC, comment #2: Netsync test is still running. I suppose its good that it hasn't crashed yet, but it's not going to be much of a workaround if it's this slow (and for all I know the problem is still there waiting to bite, it's just that netsync processes revs in a different order to the other things which fail quickly).
After 15.5 hours of pegging the pull-side cpu:
mtn: bytes in | bytes out | revs in | revs out
|
Daniel Carosone <uep>![]() |
Tue 19 Sep 2006 08:13:27 AM UTC, comment #1: also reproducible with mainline head 7b435ce7 on linux.
netsync test is still running |
Daniel Carosone <uep>![]() |
Tue 19 Sep 2006 06:11:39 AM UTC, original submission:
I trigger graph.cc:72: invariant 'I(!next.empty())' violated
When attempting to migrate the NetBSD src and pkgsrc repositories from 0.28/0.29 to 0.30. The crash happens shortly after starting the regenerate_rosters step.
The same crash can be triggered trying to cvs_import the same repository using a fresh 0.30 database. I'm currently testing to see whether it is also triggered via netsync pulling from 0.29 into an empty 0.30 db.
the dump for the regenerate_rosters case ends:
prepared statement DELETE FROM rosters WHERE id = ?
----- end '*mm_writeable' (in void database::put_roster_for_revision(const revision_id&, const revision_t&), at database.cc:1762)
----- end 'roster_manifest_id' (in void database::put_roster_for_revision(const revision_id&, const revision_t&), at database.cc:1764)
new_manifest [6babd6a7e9a0ddc6b4980870699e3379ade29192]
old_revision [879183870ad6cd621c85228e8ce0926b344c53cb]
----- end 'new_markings' (in void make_roster_for_revision(const revision_t&, const revision_id&, roster_t&, marking_map&, app_state&), at roster.cc:1820)
the dump for the import case is similar:
----- begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:20)
new_manifest [31a215e4847c525b79c7af160e625bfdae7840bd]
old_revision [2d230b6ba08c8c38190053b53a90cc626386b290]
new_manifest [31a215e4847c525b79c7af160e625bfdae7840bd]
old_revision [2d230b6ba08c8c38190053b53a90cc626386b290]
----- end '*mm_writeable' (in void database::put_roster_for_revision(const revision_id&, const revision_t&), at database.cc:1762)
----- end 'roster_manifest_id' (in void database::put_roster_for_revision(const revision_id&, const revision_t&), at database.cc:1764)
new_manifest [31a215e4847c525b79c7af160e625bfdae7840bd]
old_revision [2d230b6ba08c8c38190053b53a90cc626386b290]
----- end 'new_markings' (in void make_roster_for_revision(const revision_t&, const revision_id&, roster_t&, marking_map&, app_state&), at roster.cc:1820)
|
Daniel Carosone <uep>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 5 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
this looks like it may have been another symptom of the lru cache overflow bug fixed in a:njs/d:2006-09-22T07:01:26
test still running to confirm, but it already gets well past the point where this failed previously. taking the bug as mine until fix confirmed.