[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#945471: marked as done (britney crashes when trying removal multiple times)

Your message dated Thu, 6 Feb 2020 12:54:47 +0100
with message-id <20200206115444.GA4661@debian.org>
and subject line Re: britney crashes when trying removal multiple times
has caused the Debian Bug report #945471,
regarding britney crashes when trying removal multiple times
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
945471: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945471
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: serious
User: release.debian.org@packages.debian.org
Usertags: britney

Hi,

When a removal is done during an easy hint, the removal is tried again
afterwards, causing a crash.

There is a testcase for this in the testsuite (test takeover-removal-easy).

A workaround would be to throw an exception in this case:

https://salsa.debian.org/release-team/britney2/merge_requests/31


The root cause is that items that migrate due to the easy hint, are tried
again during the main run. This started with commit
6174d2c3f9590eba90f9c6dd613a553edd3a80e6

After this commit, the 'selected' items are no longer removed from
self.upgrade_me, because the items are represented by different objects in
both cases:

self.upgrade_me = [x for x in self.upgrade_me if x not in set(selected)]
https://salsa.debian.org/release-team/britney2/blob/master/britney.py#L1113

Example (from test takeover-removal-easy): both contain 'linux/5.3-1' and
'-linux-latest/10', but the objects are different:

selected: [<britney2.migrationitem.MigrationItem object at 0x7f09d578ab38>, <britney2.migrationitem.MigrationItem object at 0x7f09d578aba8>]
upgrade_me: [<britney2.migrationitem.MigrationItem object at 0x7f09d578ae48>, <britney2.migrationitem.MigrationItem object at 0x7f09d578a9e8>]


The commit mentioned above might have caused similar issues elsewhere in the
code.

Note that, for test takeover-removal-easy, not only '-linux-latest/10' is
tried again, but also 'linux/5.3-1'. For the latter, all binaries are removed
and added again when it 'migrates' for the second time. There are probably
corner cases where this would also cause unwanted behaviour.


In addition to a fix, it might be useful to extend the testsuite to discover
unexpected behaviour like this. One step could be to make the tests fail if a
MigrationConstraintException is triggered (except for tests where this is
explicitly allowed, because they are designed to trigger it). Also, the
consistency checks could be extended to check the validity of upgrade_me wrt
the current state of testing.

Comments welcome...

Ivo

--- End Message ---
--- Begin Message --- 
Hi,

On Thu, Jan 16, 2020 at 05:27:51PM +0100, Ivo De Decker wrote:
> The root cause of the issue is that the MigrationItem object can be versioned
> or unversioned. When comparing a versioned to an unversioned item from the
> same source, they match, however, the hashing function will return a different
> value. So whenever a set is used, this goes wrong. The way to fix this is to
> make all (relevant) migrationitems versioned and don't allow unversioned
> migration items to be hashed.

This is fixed in commit 62c309da074f24328bf55298288fc2569ac1d7fd.

Ivo

--- End Message ---
Reply to: