Bugzilla – Full Text Bug Listing
| Summary: | [solver] printout of "c The heuristics cannot find the objective function!!!!" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jed Anderson <jed.anderson> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | pascal, tim-at-eclipse | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.4 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jed Anderson
Could you please indicate which test case you are encountering that for? This occurred in one of my tests locally, unfortunately, I can't provide the details. Closing as I can't reproduce. Once scenario where this occurs for me is: - Create a new empty profile - Create a profile change request with the addition of a single group IU - Get the IPlanner and ask for the Provisioning Plan - Planner calls into PBProjector to invoke the solver In looking through the SAT4J resolver, it appears that there are no call paths from the VarOrderHeapObjective.setObjectiveFunction(...) to any P2 code. The way the objective function should be set is from the PB parser returning an objective function. I've patched the PBProjector to update the problem/solver with the objective function from the reader and this appears to solve the underlying issue. (This is modelled after how LanceurPseudo2005.solve() works) Attached is a patch that addresses the issue with the test cases I am running. The code path that triggers the System out is triggered from the planner invoking the solver: Thread [main] (Suspended (breakpoint at line 85 in VarOrderHeapObjective)) VarOrderHeapObjective.init() line: 85 PBSolverCP<L>(Solver<L,D>).isSatisfiable(IVecInt, boolean) line: 1046 PBSolverCP<L>(Solver<L,D>).isSatisfiable(IVecInt) line: 1039 PBSolverCP<L>(Solver<L,D>).isSatisfiable() line: 1020 PBProjector.invokeSolver(IProgressMonitor) line: 329 SimplePlanner.getProvisioningPlan(ProfileChangeRequest, ProvisioningContext, IProgressMonitor) line: 326 My guess from looking at this issue would be that since we are doing provisioning without a complete lineup, using the solver to resolve the full dependency graph, we are exercising different code paths than would otherwise be done. The entry IU that we are using is an IU that references a few others including a configuration IU that sets up dependencies to include the various tooling / config IUs. We don't see this function getting triggered in scenarios when using the generated 'sdk' lineup so I would assume the issue only arises in more complex resolution flows. Despite the message being printed out, it appears that the solver is for the most part doing what is expected of it though I would imagine the solver would work better with the objective function correctly configured as is done in the attached patch. Created attachment 90757 [details]
Patch to fix the issue
Attached is a patch that correctly sets the objective function prior to attempting to solve the specified problem.
This has been fixed in M6 and taken out in M7 as SAT4J got fixed. |