public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin-apps@cygwin.com
Subject: Re: [setup topic/libsolv] Crash after incomplete download
Date: Tue, 07 Nov 2017 18:15:00 -0000	[thread overview]
Message-ID: <aa7da561-29e2-4789-9d47-0901ad6228d2@dronecode.org.uk> (raw)
In-Reply-To: <2b7291f9-3df7-7f3b-6326-79bc939f595f@cornell.edu>

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...

  reply	other threads:[~2017-11-07 18:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 20:38 Ken Brown
2017-11-02 17:22 ` Jon Turney
2017-11-02 19:25   ` Ken Brown
2017-11-07 18:15     ` Jon Turney [this message]
2017-11-07 18:17       ` [PATCH setup 1/5] Make do_ini() succeed if found_ini_list is empty Jon Turney
2017-11-07 18:17         ` [PATCH setup 4/5] Correctly order preparing packagedb for chooser Jon Turney
2017-11-07 18:17         ` [PATCH setup 2/5] Simplify LocalDirPage::OnNext() Jon Turney
2017-11-07 18:17         ` [PATCH setup 3/5] Ensure packagedb and underlying solver pool is empty before we read setup.ini Jon Turney
2017-11-07 18:17         ` [PATCH setup 5/5] More crash avoidance in SolvableVersion member functions Jon Turney
2017-11-07 23:00       ` [setup topic/libsolv] Crash after incomplete download Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa7da561-29e2-4789-9d47-0901ad6228d2@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).