[pacman-dev] test/sync999 - pacman segfault

[Aurelien Foret]

VMiklos wrote:
> i would say if the problem is with the patch that improves conflict.c,
> then why not fixing conflict.c and adding a workaround to sync.c if
> possible?

Sure.

> 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?

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?

> something partially unrelated: would it be difficult to add an option to
> pactest to run "fakeroot libtool gdb --args" instead of "fakeroot" and
> in that case not to redirect the output? for now i've hardwired that
> here, but that's not a sollution :)

Added to the TODO.

Thanks
-- 
Aurelien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syncfix2.diff
Type: text/x-diff
Size: 3856 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20060223/cc8c4765/attachment.bin>