[pacman-dev] [PATCH] libalpm: avoid double free() in trans_free()
hi http://frugalware.org/~vmiklos/patches/libpacman-proposed/trans_double_free.... trans->packages is only a list of package _pointers_ so using FREELISTPKGS() on it will cause a double free(). use FREELISTPTR instead how to reproduce this bug: $ sudo pacman -Rs k9copy --noconfirm checking dependencies... done. Targets: k9copy toolame removing k9copy... done. removing toolame... done. *** glibc detected *** double free or corruption (!prev): 0x0824eea0 *** udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
hi
http://frugalware.org/~vmiklos/patches/libpacman-proposed/trans_double_free....
trans->packages is only a list of package _pointers_ so using FREELISTPKGS() on it will cause a double free(). use FREELISTPTR instead
how to reproduce this bug: $ sudo pacman -Rs k9copy --noconfirm checking dependencies... done.
Targets: k9copy toolame
removing k9copy... done. removing toolame... done. *** glibc detected *** double free or corruption (!prev): 0x0824eea0 ***
udv / greetings, VMiklos
Basically, trans->pacakges is really a list of packages, and not a list of pointers to packages. As a consequence, it must be freed by using FREELISTPKGS. See add_loadtarget() or remove_loadtarget(): data are built from scratch and copied into that list. FYI, it is needed for a transaction to hold its own set of data. During the transaction life, the package cache can change, and thus, it is tricky to rely on it by simply using pointers. IMO, the double free fault comes from somewhere else. Is it only occurring when using the "-s" flag? Is running "sudo pacman -R --noconfirm k9copy toolame" triggers the fault? -- Aurelien
On Sat, Dec 31, 2005 at 06:32:36PM +0100, Aurelien Foret <aurelien@archlinux.org> wrote:
Basically, trans->pacakges is really a list of packages, and not a list of pointers to packages. As a consequence, it must be freed by using FREELISTPKGS.
See add_loadtarget() or remove_loadtarget(): data are built from scratch and copied into that list.
hm, yes
IMO, the double free fault comes from somewhere else. Is it only occurring when using the "-s" flag? Is running "sudo pacman -R --noconfirm k9copy toolame" triggers the fault?
no, it doesn't udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Sun, Jan 01, 2006 at 02:01:03PM +0100, VMiklos <vmiklos@frugalware.org> wrote:
On Sat, Dec 31, 2005 at 06:32:36PM +0100, Aurelien Foret <aurelien@archlinux.org> wrote:
Basically, trans->pacakges is really a list of packages, and not a list of pointers to packages. As a consequence, it must be freed by using FREELISTPKGS.
See add_loadtarget() or remove_loadtarget(): data are built from scratch and copied into that list.
hm, yes
no, i was wrong. sortbydeps() will only copy the pointers, what's why we only need FREELISTPTR() there udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
On Sun, Jan 01, 2006 at 02:01:03PM +0100, VMiklos <vmiklos@frugalware.org> wrote: no, i was wrong. sortbydeps() will only copy the pointers, what's why we only need FREELISTPTR() there
I don't say FREELISTPKGS should be always used when dealing with trans->packages. But, the point was to discuss your patch which basically calls FREELISTPTR instead of FREELISTPKGS from the trans_free function. In this specific function, the latter _must_ be used (obviously if we're not in the case of a SYNC transaction). Can you please confirm that the bug we are discussing is occurring with the code from the official ArchLinux CVS tree? Thanks -- Aurelien
On Mon, Jan 02, 2006 at 08:47:29AM +0100, Aurelien Foret <aurelien@archlinux.org> wrote:
I don't say FREELISTPKGS should be always used when dealing with trans->packages.
But, the point was to discuss your patch which basically calls FREELISTPTR instead of FREELISTPKGS from the trans_free function. In this specific function, the latter _must_ be used (obviously if we're not in the case of a SYNC transaction).
okay, unfortunatelly i was speaking not about trans_free(). you have reason :)
Can you please confirm that the bug we are discussing is occurring with the code from the official ArchLinux CVS tree?
vmiklos@vmobile:~/cvs/pacman-lib/src/pacman$ sudo ./pacman.static -Rs k9copy checking dependencies... done. Targets: k9copy toolame Do you want to remove these packages? [Y/n] removing k9copy... done. removing toolame... done. *** glibc detected *** double free or corruption (!prev): 0x0824f610 *** udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
vmiklos@vmobile:~/cvs/pacman-lib/src/pacman$ sudo ./pacman.static -Rs k9copy checking dependencies... done.
Targets: k9copy toolame
Do you want to remove these packages? [Y/n]
removing k9copy... done. removing toolame... done. *** glibc detected *** double free or corruption (!prev): 0x0824f610 ***
I've found and fixed a memory corruption in the removedeps function. It should be ok by now. Can you confirm it is working for you? Thanks -- Aurelien
On Tue, Jan 03, 2006 at 12:19:28AM +0100, Aurelien Foret <aurelien@archlinux.org> wrote:
I've found and fixed a memory corruption in the removedeps function.
just found the same bug :)
It should be ok by now. Can you confirm it is working for you?
yes, it does btw my version is available at http://frugalware.org/~vmiklos/patches/libpacman-proposed/trans_double_free2... udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
participants (2)
-
Aurelien Foret
-
VMiklos