[pacman-dev] cvs unusable on x86_64
hi just wanted to let you know that the current cvs segfaults on pacman -S anything. i'm not sure about what is the problem, reverting this diff: http://frugalware.org/~vmiklos/patches/pacman_progress.diff works around the problem. i've tried to fix it but i don't see any problem. it should be some memory corruption since if the build is debug-enabled then it works fine since i'm not the author of the change, it's not my task to fix it - good luck for now i've reverted it in our tree udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On 10/23/06, VMiklos <vmiklos@frugalware.org> wrote:
works around the problem. i've tried to fix it but i don't see any problem. it should be some memory corruption since if the build is debug-enabled then it works fine
I attempted 2 rather random changes to see if it affects anything - right now I have no way to test this (no 64bit machines), so can you please let me know if it fixes anything? I prefixed the string with the max length, as a safeguard, and switch the unsigned chars to unsigned ints, in the off-chance that _that_ has some effect, though I expect it's string related. Please let me know either way.
On Mon, Oct 23, 2006 at 11:52:32PM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I attempted 2 rather random changes to see if it affects anything - right now I have no way to test this (no 64bit machines), so can you please let me know if it fixes anything? I prefixed the string with the max length, as a safeguard, and switch the unsigned chars to unsigned ints, in the off-chance that _that_ has some effect, though I expect it's string related.
Please let me know either way.
still segfaults. i would suggest asking a shell access from an Arch64 dev, i neither have such a machine phisically. anyway here is the commandline to reproduce the issue: vmiklos@helicon:~/darcs/pacman/src/pacman$ sudo rm -f /var/cache/pacman/pkg/vim* /tmp/pacman.lck; sudo ./pacman -Sw vim --noconfirm resolving dependencies... done. Targets: vim-7.0-2 Total Package Size: 5.0 MB Total Uncompressed Package Size: 16.3 MB Beginning download... :: Retrieving packages from frugalware-current... Internal pacman error: Segmentation fault00:00:00 [ ] 0% Please submit a full bug report, with the given package if appropriate. udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
still segfaults. i would suggest asking a shell access from an Arch64 dev, i neither have such a machine phisically. anyway here is the commandline to reproduce the issue:
vmiklos@helicon:~/darcs/pacman/src/pacman$ sudo rm -f /var/cache/pacman/pkg/vim* /tmp/pacman.lck; sudo ./pacman -Sw vim --noconfirm resolving dependencies... done.
Targets: vim-7.0-2
Total Package Size: 5.0 MB
Total Uncompressed Package Size: 16.3 MB
Beginning download...
:: Retrieving packages from frugalware-current... Internal pacman error: Segmentation fault00:00:00 [ ] 0% Please submit a full bug report, with the given package if appropriate.
Strange. I did some work at this code. I found one thing only which will be x86_64 specific. In pacman.c there is a callback point (as i remember it was in pacman.c :) ) which got some : (long)log_progress() definition. Actually in download.c (and in.h) the log_progress function is int log_progress(...) I tried to change from int -> long in download.c and .h to see that cause the problem or not. No, that wasnt :) (as you know on x86_64 int and long matters, because of size difference) So the problem still exists. I catched up some backtrace with the not debug binary pacman and seems that it segfaults at FtpRead() function. That is strange too. A notice for this, the main progressbar moves to some ~5 or 10% and crashing after that. So it will be some magic buffer overrun somewhere :S Still i will work on it (cause i got x86_64 machine) and maybe see what i can do. Regards Christian Hamar alias krix
On 10/25/06, Christian Hamar alias krix <krics@gds.hu> wrote:
So the problem still exists. I catched up some backtrace with the not debug binary pacman and seems that it segfaults at FtpRead() function.
That is strange too.
A notice for this, the main progressbar moves to some ~5 or 10% and crashing after that. So it will be some magic buffer overrun somewhere :S
Apparently this does not crash under Arch64, according to Varun: ./pacman -S aterm resolving dependencies... done. looking for inter-conflicts... done. Targets: aterm-1.0.0-2 Total Package Size: 0.1 MB Proceed with upgrade? [Y/n] y :: Retrieving packages from current... aterm-1.0.0-2 73K 13.5K/s 00:00:05 [#######################] 100% checking package integrity... done. checking for file conflicts (1/1) [#######################] 100% (1/1) installing aterm [#######################] 100% So, no segfault for me. :)
On Wed, Oct 25, 2006 at 08:14:31AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
So, no segfault for me. :)
is it a debug-disabled+stripped pacman? udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On 10/25/06, VMiklos <vmiklos@frugalware.org> wrote:
On Wed, Oct 25, 2006 at 08:14:31AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
So, no segfault for me. :)
is it a debug-disabled+stripped pacman?
Apparently, this problem goes away with -O1. Thanks to kpiche for debugging this out. It appears 'ctl' gets optimized away inside FtpRead... silly compilers. 8)
participants (3)
-
Aaron Griffin
-
Christian Hamar alias krix
-
VMiklos