I looked at this too. The SIG11 goes away if you compile without -O2. When looking at it with gdb most function arguments seemed to be "optimized out". If you compile without the -O2 it still displays strangely. The SIG11 happens when vim*.part starts downloading. Frankly I don't like ftplib - it doesn't work with proxies so I have to use wget. Maybe we should switch to libcurl or something. k -----Original Message----- From: pacman-dev-bounces@archlinux.org [mailto:pacman-dev-bounces@archlinux.org] On Behalf Of Christian Hamar alias krix Sent: Wednesday, October 25, 2006 7:42 AM To: Discussion list for pacman development Subject: Re: [pacman-dev] cvs unusable on x86_64
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 _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev