[pacman-dev] test/sync999 - pacman segfault

VMiklos vmiklos at frugalware.org
Thu Feb 23 18:36:38 EST 2006

On Thu, Feb 23, 2006 at 11:12:30PM +0100, Aurelien Foret <aurelien at archlinux.org> wrote:
> >the sync.c patch contains two hunk: a workaround for the conflict.c
> >problem and a compile fix (would it be a big problem not to mix compile
> >fixes and workarounds?) if you revert the workaround, and apply this
> >patch:
> >http://frugalware.org/~vmiklos/patches/libpacman-proposed/syncfix.diff
> >i hope the test will pass again (this time without the workaround)
> Which sync.c patch are you mentioning?

ah, sorry, i run cvs diff -u -r 1.65 sync.c, not cvs diff -u -r 1.65 sync.c

so i got a patch that included two revisions

Judd: would it be a big task to include pacman-lib in the cvsweb
interface? :)

(<flame>man, after darcs, using centralized version control systems are
so annoying ;) </flame>)

> If it's my patch (sync.c 1.65-1.66), there's only one hunk
> There's no compile fix in it, just a fix to avoid a segmentation fault.
> If it's your patch, there are 3 hunks...
> You're basically switching "j" and "k", and it fixes the issue by chance because you 
> forgot to also switch "j" and "k" at line 159.
> With your patch applied, at line 159, j->data has become a (pmpkg_t *) that will for 
> sure never make strcmp return 0...
> Anyway, I think the issue comes from the _alpm_depmiss_new declarations for CHECK3 that 
> are switching tp->name and info->name.
> I'm attaching a patch based on yours fixing that point.
> Thoughts?

seems ok to me

udv / greetings,

Developer of Frugalware Linux, to make things frugal - http://frugalware.org

More information about the pacman-dev mailing list