Merge lp:~brian-murray/apport/contents-mapping into lp:~apport-hackers/apport/trunk
Status: | Merged |
---|---|
Merged at revision: | 3211 |
Proposed branch: | lp:~brian-murray/apport/contents-mapping |
Merge into: | lp:~apport-hackers/apport/trunk |
Diff against target: |
148 lines (+75/-30) 1 file modified
backends/packaging-apt-dpkg.py (+75/-30) |
To merge this branch: | bzr merge lp:~brian-murray/apport/contents-mapping |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Dimitri John Ledkov (community) | Approve | ||
Apport upstream developers | Pending | ||
Review via email: mp+356447@code.launchpad.net |
Description of the change
This modifies apport-retrace so that it stops searching each Contents.gz files for every file that appears in ProcMaps until it finds a match. Instead a global mapping of files to packages is created and saved to disk so that subsequent file lookups and retraces are quicker.
Its worth noting that not every file in Contents.gz is added to the mapping because not every file which exists in ProcMaps is utilized as a search criteria for Contents.gz. You can see the filtering in the needed_
I've tested it with sample crashes from every supported release of Ubuntu without issue.
I hope this works correctly with our "old" and "new" Contents files (with/without headers, ubuntu- only/debian- like) -> the hardcoded checks of 33 lines is ok, as long as we don't re-publish release pocket...
I wonder if this will at all work when we enable usr-merge, as Contents will still list "old" locations, which actually will be installed/loaded from new locations. But this is good, cause we will be able to create additional contents_mappings for alternative paths (as in /bin/bash and /usr/bin/bash become equivalent).
The pickle loading appears to be safe, as the mapping is only user-writable by default (including when using a tempdir).