From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93168 invoked by alias); 7 Nov 2017 18:15:51 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 93154 invoked by uid 89); 7 Nov 2017 18:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Back, problems!, visit, site X-HELO: out4-smtp.messagingengine.com Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Nov 2017 18:15:49 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8BC0120A92 for ; Tue, 7 Nov 2017 13:15:47 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 07 Nov 2017 13:15:47 -0500 X-ME-Sender: Received: from [192.168.1.102] (host86-162-230-154.range86-162.btcentralplus.com [86.162.230.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 3BBBB2494B for ; Tue, 7 Nov 2017 13:15:47 -0500 (EST) Subject: Re: [setup topic/libsolv] Crash after incomplete download To: cygwin-apps@cygwin.com References: <4966bc07-8a00-3324-6b6f-4da2213e974c@cornell.edu> <2ad6ea16-ef19-ae4e-757f-9e9b882aba75@dronecode.org.uk> <2b7291f9-3df7-7f3b-6326-79bc939f595f@cornell.edu> From: Jon Turney Message-ID: Date: Tue, 07 Nov 2017 18:15:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2b7291f9-3df7-7f3b-6326-79bc939f595f@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-11/txt/msg00019.txt.bz2 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...