| Summary: | Improve taskhash mismatch diagnostics | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Jonathan Liu <net147> |
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | Juan Ramos <juan.fernandox.ramos.frayle> |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | jose.perez.carranza, joshuagloe, poky.bs.watcher, poky.watcher |
| Version: | unspecified | ||
| Target Milestone: | 2.3 M1 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Jonathan Liu
2016-10-01 09:56:26 UTC
This sounds simple in principle. In practise, it means writing out the stamp files at parse time and this literally doubles the parsing overhead/time. Is slowing down parsing to that degree acceptable to fix this? (In case its not clear, the problem is that the hash can change from the initial parsing compared to when the task runs. We need to save that data at original parse time since we have no idea why its changed later and hence have nothing to compare it to. I have looked into and thought about this but have been unable to find an easy way to avoid the problems) Can it be disabled by default and enabled using an environment variable? Then when the mismatch occurs it can tell the user to enable the environment variable at the cost of some parsing time if it isn't enabled. (In reply to comment #2) > Can it be disabled by default and enabled using an environment variable? > Then when the mismatch occurs it can tell the user to enable the environment > variable at the cost of some parsing time if it isn't enabled. Sadly this doesn't help in most cases as the issue causing the mismatch may or may not reproduce when it reparses, usually not :(. I looked into this a bit and posted on the mailing list with my results. I found various problems, including cases where hash files were being overwritten with incorrect data, or where they were being removed when they shouldn't have been. There were patches to both bitbake and OE-Core, in and around this patch: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master&id=0a4a6d6956a10aa0a6589de12b0b2380a9f0a7d9 If you uncomment the commented code mentioned in this commit and trigger a reparse, you can at least get better debugging information. Ideally we'd save the data we need all the time but I haven't managed to come up with a way of doing that which doesn't have performance issues as yet. These changes do make the taskhash problems much more debuggable IMO. I'm open to further bugs with specific proposals on how we can further improve it but I've done all I can think of right now. |