[setup topic/libsolv] Crash after incomplete download
Jon Turney
jon.turney@dronecode.org.uk
Tue Nov 7 18:15:00 GMT 2017
On 02/11/2017 19:25, Ken Brown wrote:
> On 11/2/2017 1:22 PM, Jon Turney wrote:
>> On 01/11/2017 20:38, Ken Brown wrote:
>>> If there is a download failure and the user clicks Yes in response to
>>> "Download Incomplete. Try again?", then setup will crash. The crash
>>> occurs at PickView.cc:447 because i->source() is NULL.
>>
>> Thanks for finding all these problems!
>>
>>> I haven't yet analyzed this in further detail, but the crux of the
>>> issue seems to be that we call do_ini_thread a second time without
>>> having cleaned out the package database and the libsolv pool.
>>>
>>> This is probably a symptom of a more general problem, which is that
>>> we haven't thought carefully (or at least I haven't) about what
>>> happens when we visit certain pages for a second time, after the
>>> libsolv pool has been created.
>>
>> The fact that this isn't considered at all at the moment makes me
>> wonder if it's working correctly in this situation currently. But,
>> yeah, I agree that packagedb state should be cleared in this case.
>>
>> I tried with the attached, but it still segfaults at the same place.
>>
>> This seems to be because all the packagedb prep (including
>> fixup_source_package_ids) is in OnInit() (which is only called once
>> per page, but lazily), rather than OnActivate(), so probably some more
>> restructuring is needed there :(
>
> I guess we could move all that prep to OnActivate() but make sure it's
> only run when we've gotten to the chooser page from the site page (and
> not because the user pressed Back on the prereq page). What about
> adding a 'prepped' data member to packagedb and using this to decide
> whether to run the prep code?
An attempt at this to follow, but this ended up touching rather more
stuff than I wanted to, so I'm sure something else has broken :(
>> +void
>> +packagedb::init ()
>> +{
>> +Â installeddbread = 0;
>> +Â installeddbver = 0;
>> +Â packages.clear();
>> +Â sourcePackages.clear();
>> +Â categories.clear();
>> +Â solver.clear();
>> +Â basepkg = packageversion();
>> +Â dependencyOrderedPackages.clear();
>
> I think you also need solution.clear(), where the latter does
> essentially what SolverSolution::~SolverSolution() does. (Or is it
> enough to just set solv = NULL?)Â Otherwise, solv will be an invalid
> pointer when update is next called.
Yes, you're right, of course.
The initialization all gets a bit obscure, maybe making solver and
solversolution directly members of this singleton isn't the right
approach...
More information about the Cygwin-apps
mailing list