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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
