|
Bugzilla – Full Text Bug Listing |
| Summary: | installation crashes when solving for the first inst. proposal | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Jan Kupec <jkupec> |
| Component: | libzypp | Assignee: | Michael Schröder <mls> |
| Status: | RESOLVED FIXED | QA Contact: | Duncan Mac-Vicar <dmacvicar> |
| Severity: | Blocker | ||
| Priority: | P5 - None | CC: | matz |
| Version: | Alpha 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | yast logs | ||
|
Description
Jan Kupec
2008-01-17 11:46:43 UTC
might be related to or a duplicate of bug 354410 The trunk version of libzypp generates now a testcase BEFORE the solver will be started. (/var/log/YaST/autotestcase). So can cou please try to reproduce this error and send me the testcase ? Thank you ! I'll try to reproduce it with Alpha2 then. In the meantime please check bug 354410 as it might be the same problem. If we will be unable to reproduce this bug during installation (upgrade) to some of the Alphas after 354410 will be fixed, we can consider this bug a duplicate. the bug is here:
c = solv->rules + why;
-->fix dp = c->d ? pool->whatprovidesdata + c->d : 0;
IF_POOLDEBUG (SAT_DEBUG_ANALYZE)
printruleclass(solv, SAT_DEBUG_ANALYZE, c);
for (i = -1; ; i++)
{
if (i == -1)
v = c->p;
else if (c->d == 0)
v = i ? 0 : c->w2;
else
---->null pointer v = *dp++;
if (v == 0)
break;
if (DECISIONMAP_TRUE(v)) /* the one true literal */
continue;
vv = v > 0 ? v : -v;
l = solv->decisionmap[vv];
if (l != 1 && l != -1)
continue;
MAPSET(&seen, vv);
}
}
I have tried to fix it but then a assertion happens on another point:
solver.c:638: makeruledecisions: Assertion `ri < solv->learntrules' failed.
*** Bug 354410 has been marked as a duplicate of this bug. *** I've committed the obvious fix for the segfault, which I'm fairly sure is correct (iterating the literals of a rule requires looking into (pool->whatprovidesdata + rule->d)). So, the segfault is fixed. The assertion we now see must have different reasons. What the solver checks with the assertion is that it doesn't try to disable a rule which it just learned, because that would mean that it was presented with an inherently unsolvable problem. It is a bug in the solver that this isn't prevented, but this bug is _triggered_ by some problem in the libzypp setup of the SAT pool (i.e. if the problem as given would be solvable the bug wouldn't be triggered). It's interesting that using deptestomatic from sat-solver (i.e. using SOLV files) this update has a solution. But the input is different. What libzypp asks of the solver is basically a long stream of Install and Delete package jobs (I don't know why, it comes from SATResolver::resolvePool, in iterating the _items_to_install and _items_to_remove lists, which are filled it seems from the Transact status of all zypp pool solvables). sat-solver deptestomatic doesn't register any jobs at all, but simply sets the updatesystem policy. That then leads to a solution (which looks sane). So: libzypp registers a whole set of individual install/delete jobs, which maybe (!) are inconsistent. Fixed. |