Re: [pacman-dev] cvs unusable on x86_64
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
On 10/25/06, Piche, Kevin
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.
On this note, I agree 100% - but libcurl is messy. I would prefer something along the lines of libarchive - maybe libfetch (also from bsd) ? Are you sure this is an ftplib issue?
2006. 10. 25, szerda keltezéssel 10.56-kor Aaron Griffin ezt írta:
On 10/25/06, Piche, Kevin
wrote: 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.
On this note, I agree 100% - but libcurl is messy. I would prefer something along the lines of libarchive - maybe libfetch (also from bsd) ?
For points. I agree with that we need to replace ftplib with some "newer" and some active developed project. Because as i see ftplib dead (development) I dont know libcurl. And never hear from libfetch :) Maybe i see libfetch in these days. I support this idea. Regards Christian Hamar alias krix
2006/10/25, Christian Hamar alias krix
2006. 10. 25, szerda keltezéssel 10.56-kor Aaron Griffin ezt írta:
On 10/25/06, Piche, Kevin
wrote: 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.
On this note, I agree 100% - but libcurl is messy. I would prefer something along the lines of libarchive - maybe libfetch (also from bsd) ?
For points. I agree with that we need to replace ftplib with some "newer" and some active developed project. Because as i see ftplib dead (development)
I dont know libcurl. And never hear from libfetch :) Maybe i see libfetch in these days.
I support this idea.
libcurl is the most featured and thus too heavy for Pacman, IMHO. I don't know if compiling it with some featuress omitted will help much. A list of libraries can be found at http://curl.haxx.se/libcurl/competitors.html libfetch seems to be nice alternative to ftplib. It is small, has simple and stable API, is maintained, supports HTTP and FTP downloads and uploads, HTTP proxies and redirects. Sources are here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/ -- Roman Kyrylych (Роман Кирилич)
libcurl is the most featured and thus too heavy for Pacman, IMHO. I don't know if compiling it with some featuress omitted will help much. A list of libraries can be found at http://curl.haxx.se/libcurl/competitors.html
Exactly. curl is too heavy for this.
libfetch seems to be nice alternative to ftplib. It is small, has simple and stable API, is maintained, supports HTTP and FTP downloads and uploads, HTTP proxies and redirects. Sources are here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/
Yes as i see. Its great and simple. And it supports file:/// too! Which is not bad. Since as i know pacman now got "own" routin for handling those types. I support libfetch! :) Vote for libfetch! libfetch for President! :) (sorry :) ) Regards -krix-
2006/10/25, Christian Hamar alias krix
libfetch seems to be nice alternative to ftplib. It is small, has simple and stable API, is maintained, supports HTTP and FTP downloads and uploads, HTTP proxies and redirects. Sources are here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/
Yes as i see. Its great and simple. And it supports file:/// too! Which is not bad. Since as i know pacman now got "own" routin for handling those types.
I support libfetch! :)
Vote for libfetch! libfetch for President! :) (sorry :) )
libfetch is licensed under BSD license with some parts of code under MIT license. As they both are compatible with GPL I think there is no reason why not to use libfetch. ;-) -- Roman Kyrylych (Роман Кирилич)
On 10/25/06, Roman Kyrylych
2006/10/25, Christian Hamar alias krix
: libfetch seems to be nice alternative to ftplib. It is small, has simple and stable API, is maintained, supports HTTP and FTP downloads and uploads, HTTP proxies and redirects. Sources are here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/
Yes as i see. Its great and simple. And it supports file:/// too! Which is not bad. Since as i know pacman now got "own" routin for handling those types.
I support libfetch! :)
Vote for libfetch! libfetch for President! :) (sorry :) )
libfetch is licensed under BSD license with some parts of code under MIT license. As they both are compatible with GPL I think there is no reason why not to use libfetch. ;-)
libfetch is a PITA to port... we'll probably have to fork it... as the changes in the pas year or so have been minimal, I don't forsee a problem with that.... I'm gonna try this out
2006/10/25, Aaron Griffin
libfetch is a PITA to port... we'll probably have to fork it... as the changes in the pas year or so have been minimal, I don't forsee a problem with that.... I'm gonna try this out
Why it's so PITA? Does libftp use many FreeBSD-specific things? Maybe you should take a look how it's ported by GNU-Darwin project here: http://gnu-darwin.cvs.sourceforge.net/gnu-darwin/4linux/libfetch/ The description of 4linux says "FreeBSD ports and package system as modified for GNU/Linux". I know that this is outdated version, but maybe you can find some hints how to port the latest version here. Yes, libfetch is not changing constantly, so if there will be some patches in mainstream we can port them easy. I wonder if there will be any non-security-related/non-bugfix patches at all, as libfetch API was last changed in 4 years, 10 months ago! -- Roman Kyrylych (Роман Кирилич)
On 10/26/06, Roman Kyrylych
2006/10/25, Aaron Griffin
: libfetch is a PITA to port... we'll probably have to fork it... as the changes in the pas year or so have been minimal, I don't forsee a problem with that.... I'm gonna try this out
Why it's so PITA? Does libftp use many FreeBSD-specific things?
It's a pain in the ass because they use alot of stuff that, while available under GNU, are totally different. i.e. funopen <-> fopencookie Regardless, it's fixed and I integrated it into pacman. It was pretty quick, and let me remove about 500 lines. I also got to change the download callback format (thank god), as using about 50 different 'global' variables was disgusting. Of course, this breaks some things until they use the new format (assuming it's ok). To the frugalware devs: do you have anything that uses the dlcb function besides pacman? Anyway, I didn't check anything in, as it's a handful of breaking changes to the frontends. PS I also added ILoveCandy to the other progress bars 8)
2006/10/26, Aaron Griffin
Regardless, it's fixed and I integrated it into pacman. It was pretty quick, and let me remove about 500 lines. I also got to change the download callback format (thank god), as using about 50 different 'global' variables was disgusting. Of course, this breaks some things until they use the new format (assuming it's ok).
Aaron, it will be really cool if you make a Linux port of libfetch available not only from Arch CVS. AFAIK many people want something like libfetch under Linux. (I realized this even more while searched over Internet for Linux port of it) -- Roman Kyrylych (Роман Кирилич)
On 10/26/06, Roman Kyrylych
2006/10/26, Aaron Griffin
: Regardless, it's fixed and I integrated it into pacman. It was pretty quick, and let me remove about 500 lines. I also got to change the download callback format (thank god), as using about 50 different 'global' variables was disgusting. Of course, this breaks some things until they use the new format (assuming it's ok).
Aaron, it will be really cool if you make a Linux port of libfetch available not only from Arch CVS. AFAIK many people want something like libfetch under Linux. (I realized this even more while searched over Internet for Linux port of it)
I plan on it, but I will fork it. One of my tabled projects, for a long time, has been a decent "download" library for using external resources. I plan on adding segmented downloading among other things (torrent and metalink support?), but that may be a long ways off. I will provide a patch to allow libfetch to compile under linux, mostly unmolested, but I also plan on forking this for my own ideas 8)
2006/10/26, Aaron Griffin
Aaron, it will be really cool if you make a Linux port of libfetch available not only from Arch CVS. AFAIK many people want something like libfetch under Linux. (I realized this even more while searched over Internet for Linux port of it)
I plan on it, but I will fork it. One of my tabled projects, for a long time, has been a decent "download" library for using external resources. I plan on adding segmented downloading among other things (torrent and metalink support?), but that may be a long ways off. I will provide a patch to allow libfetch to compile under linux, mostly unmolested, but I also plan on forking this for my own ideas 8)
Yes, I meant the fork. :-) Hmm... segmented downloads? Yay! That's really cool 8-D -- Roman Kyrylych (Роман Кирилич)
On Thu, Oct 26, 2006 at 03:45:14PM -0500, Aaron Griffin wrote:
On 10/26/06, Roman Kyrylych
wrote: 2006/10/26, Aaron Griffin
: Regardless, it's fixed and I integrated it into pacman. It was pretty quick, and let me remove about 500 lines. I also got to change the download callback format (thank god), as using about 50 different 'global' variables was disgusting. Of course, this breaks some things until they use the new format (assuming it's ok).
Aaron, it will be really cool if you make a Linux port of libfetch available not only from Arch CVS. AFAIK many people want something like libfetch under Linux. (I realized this even more while searched over Internet for Linux port of it)
I plan on it, but I will fork it. One of my tabled projects, for a long time, has been a decent "download" library for using external resources. I plan on adding segmented downloading among other things (torrent and metalink support?), but that may be a long ways off. I will provide a patch to allow libfetch to compile under linux, mostly unmolested, but I also plan on forking this for my own ideas 8)
Good Point. I also thought about this. I would prefer removing any file retrieving functionality from pacman. Retrieving package-databases and packages should be the duty of another program. As in Unix philosophy: "Make each program do one thing well". Same applies to package signing: If features (not related to core packet management) will be moved to pacman we will loose flexibility and end up with a book like Maximum Pacman which covers 450 Pages ;) Jürgen
On Wed, 2006-10-25 at 10:56 -0500, Aaron Griffin wrote:
On 10/25/06, Piche, Kevin
wrote: 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.
On this note, I agree 100% - but libcurl is messy. I would prefer something along the lines of libarchive - maybe libfetch (also from bsd) ?
Are you sure this is an ftplib issue?
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
While the SIG11 occurs within ftplib I think it's more of a compiler
issue actually after more investigation. There's nothing obviously
wrong with the code however. Here's my gdb trace:
[23:01 root@puffin pacman]$ gdb --args ./pacman.static -vSw vim
--noconfirm
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-unknown-linux-gnu"...Using host
libthread_db
library "/lib/libthread_db.so.1".
(gdb) break FtpGet
Breakpoint 1 at 0x41e400: file ftplib.c, line 1248.
(gdb) run
Starting
program: /home/kpiche/pacman-devel/src/pacman-lib/src/pacman/pacman.static -vSw vim --noconfirm
Root : /
DBPath: var/lib/pacman
Targets: vim
resolving dependencies... done.
Targets: vim-7.0.118-1
Total Package Size: 7.6 MB
Beginning download...
:: Retrieving packages from current...
Breakpoint 1, FtpGet (
outputfile=0x7fff3c50e470
"/var/cache/pacman/pkg/vim-7.0.118-1.pkg.tar.gz.part", path=0x7742a0
"vim-7.0.118-1.pkg.tar.gz", mode=73 'I', nControl=0x777810)
at ftplib.c:1248
1248 {
(gdb) s
1249 return FtpXfer(outputfile, path, nControl,
FTPLIB_FILE_READ, mode);
(gdb)
FtpXfer (
localfile=0x7fff3c50e470
"/var/cache/pacman/pkg/vim-7.0.118-1.pkg.tar.gz.part", path=0x7742a0
"vim-7.0.118-1.pkg.tar.gz", nControl=0x777810, typ=3,
mode=73) at ftplib.c:1101
1101 {
(gdb)
1108 if (localfile != NULL)
(gdb)
1101 {
(gdb)
1108 if (localfile != NULL)
(gdb)
1110 char ac[4] = "a";
(gdb)
1112 ac[0] = 'r';
(gdb)
1115 local = fopen(localfile, ac);
(gdb)
1110 char ac[4] = "a";
(gdb)
1112 ac[0] = 'r';
(gdb)
1114 ac[1] = 'b';
(gdb)
1112 ac[0] = 'r';
(gdb)
1114 ac[1] = 'b';
(gdb)
1115 local = fopen(localfile, ac);
(gdb)
1116 if (local == NULL)
(gdb)
1115 local = fopen(localfile, ac);
(gdb)
1116 if (local == NULL)
(gdb)
1125 if (!FtpAccess(path, typ, mode, nControl, &nData))
(gdb)
FtpAccess (path=0x7742a0 "vim-7.0.118-1.pkg.tar.gz", typ=3, mode=73,
nControl=0x777810, nData=0x7fff3c50d3c8) at ftplib.c:802
802 {
(gdb)
805 if ((path == NULL) &&
(gdb) print nControl
$1 = (netbuf *) 0x777810
(gdb) print nControl->idlecb
$2 = (FtpCallback) 0x401e70
0) (gdb) FtpRead (buf=0x779d60, max=8192, nData=0x779be0) at ftplib.c:872 872 { (gdb) 874 if (nData->dir != FTPLIB_READ) (gdb) print nData $4 = (netbuf *) 0x779be0 (gdb) l 869 * FtpRead - read from a data connection 870 */ 871 GLOBALDEF int FtpRead(void *buf, int max, netbuf *nData) 872 { 873 int i; 874 if (nData->dir != FTPLIB_READ) 875 return 0; 876 if (nData->buf) 877 i = readline(buf, max, nData); 878 else (gdb) print nData->dir $5 = 1 (gdb) $6 = 1 (gdb) s 872 { (gdb) 874 if (nData->dir != FTPLIB_READ) (gdb) 876 if (nData->buf) (gdb) print nData->buf $7 = 0x0 (gdb) s
So here FtpRead is about to call socket_wait. Note the value of the
control structure pointer is 0x779be0.
880 i = socket_wait(nData);
(gdb) print nData
$8 = (netbuf *) 0x779be0
(gdb) s
socket_wait (ctl=0x779be0) at ftplib.c:144
144 {
(gdb)
148 if ((ctl->dir == FTPLIB_CONTROL) || (ctl->idlecb ==
NULL))
(gdb) print ctl->idlecb
$9 = (FtpCallback) 0x401e70
On 10/26/06, K. Piche
The wierd thing is that ctl is not modified by log_progress. The only explanation I can think of besides a compiler optimization bug is that log_progress accesses the fsz variable which is just before the ctl variable in main. Moving the variable may fix it or refactoring the code in socket_wait to get different assembler output.
This is a close as anything could possibly come to modifying ctl, but in this case it's just being silly and preventing compier warnings, I'd assume. src/pacman/download.c /* we don't need that parameter */ ctl=NULL; Just in case the compiler decides to do-something-it-shouldn't, could you try switching this to a: /* we don't need that parameter */ (void)ctl; That's as close as I can get
On Thu, 2006-10-26 at 17:20 -0500, Aaron Griffin wrote:
On 10/26/06, K. Piche
wrote: The wierd thing is that ctl is not modified by log_progress. The only explanation I can think of besides a compiler optimization bug is that log_progress accesses the fsz variable which is just before the ctl variable in main. Moving the variable may fix it or refactoring the code in socket_wait to get different assembler output.
This is a close as anything could possibly come to modifying ctl, but in this case it's just being silly and preventing compier warnings, I'd assume.
src/pacman/download.c /* we don't need that parameter */ ctl=NULL;
Just in case the compiler decides to do-something-it-shouldn't, could you try switching this to a: /* we don't need that parameter */ (void)ctl;
That's as close as I can get
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
I commented the ctl=NULL to no effect. Halfway stepping through log_progress ctl gets optimized away which somehow affects the caller which it obviously shouldn't. I tried playing around with the do {} while loop to hopefully get different code generation to no avail. Since log_progress always returns 1 the loop can become: if (stuff) break; blah ctl->idlecb(blah) } while (1) But ctl still disappears. Compiling with -O1 works as a workaround. k
On 10/27/06, K. Piche
But ctl still disappears. Compiling with -O1 works as a workaround.
Interesting. A frugalware user reported that compiling with -D_REENTRANT_ also worked, however pacman is not threaded, so that should not affect anything.
participants (6)
-
Aaron Griffin
-
Christian Hamar alias krix
-
Jürgen Hötzel
-
K. Piche
-
Piche, Kevin
-
Roman Kyrylych