Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#23731 - [libalpm] alpm_add_pkg() eats your packages and leads to double free's

Attached to Project: Pacman
Opened by Rémy Oudompheng (remyoudompheng) - Tuesday, 12 April 2011, 22:40 GMT
Task Type Feature Request
Category Backend/Core
Status Assigned
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version 3.5.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:
The function alpm_add_pkg() that adds a package to a transaction may transfer the ownership of a pmpkg_t object (allocated by alpm_pkg_load()) from the program to the library.
This behaviour is undocumented and easily leads developers to double free pmpkg_t's because they don't know that a package (which they thought they had the responsability to free) suddenly becomes managed by libalpm and gets freed on its own afterwards.

Steps to Reproduce:
* load a package from a file with alpm_pkg_load()
* add it to a transaction with alpm_add_pkg()
* commit the transaction
* free the package
This task depends upon

Comment by Dan McGee (toofishes) - Tuesday, 12 April 2011, 23:06 GMT
I'm going to say "this isn't a huge deal, it just isn't documented well". If you call alpm_add_pkg() on *any* package, you no longer manage it, period. It is pretty straightforward and this is one line added to the add_pkg() docs. Other libraries have similar behavior with buffers, etc. as we do here with a package object.
Comment by Dan McGee (toofishes) - Wednesday, 01 June 2011, 22:18 GMT
Of course I said this, and then discovered today alpm_remove_pkg actually does a dup() operation behind the scenes. I'm not sure how relevant this is, but something worth thinking about and we should probably be consistent in some fashion.

Loading...