Re: [SCM] dpkg's main repository branch, master, updated. 1.16.0.3-191-ge135afd
Hi,
On Mon, 25 Jul 2011, Guillem Jover wrote:
> Hmm, trying to "fix" a bug w/o understanding the causes is almost never
> a good idea. In this case doubly so if this only happens in the Ubuntu
> dpkg. The commit might as well just be shifting the segfaults to a later
> point if other parts of the code are inserting new packages through
> pkg_db_find() or in areas where findbreakcycle() is not being used.
Only if there are other places where we are incorrectly assuming that
clientdata is allocated without calling ensure_package_clientdata(). This
commit is fixing one of those places, why should we revert it?
If pkg_db_find must not create new packages on the fly, we should
consider changing its API instead. But I don't think that it's really
reasonable to expect some parts of the code to not have the right to use
pkg_db_find() because we fear that it might introduce new package entries.
So IMO the right course of action is to protect the access to clientdata
in particular when we have a segfault that proves that the initial
analysis that lead us to believe it's not needed is wrong.
> This commit is not ok and should be reverted.
What's the right course of action then?
Ignoring the problem because you don't know what part of the code
introduces the new package entry doesn't seem very reasonable.
I mean I can try to spend a couple of hours trying to find this but it
doesn't seem a very productive use of my time when the unprotected access
is so self-evident.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: