Re: cvs unusable on x86_64

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Christian Hamar alias krix

> 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
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/25/06, Christian Hamar alias krix <[hidden email]> 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. :)

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Miklos Vajna
On Wed, Oct 25, 2006 at 08:14:31AM -0500, Aaron Griffin <[hidden email]> 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

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/25/06, VMiklos <[hidden email]> wrote:
> On Wed, Oct 25, 2006 at 08:14:31AM -0500, Aaron Griffin <[hidden email]> wrote:
> > So, no segfault for me. :)
>
> is it a debug-disabled+stripped pacman?

Oh crap, no - let me have him disable debug.

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Kevin Piche
In reply to this post by Christian Hamar alias krix
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: [hidden email]
[mailto:[hidden email]] 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
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/25/06, Piche, Kevin <[hidden email]> 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
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Christian Hamar alias krix
2006. 10. 25, szerda keltezéssel 10.56-kor Aaron Griffin ezt írta:
> On 10/25/06, Piche, Kevin <[hidden email]> 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



_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Roman Kyrylych
2006/10/25, Christian Hamar alias krix <[hidden email]>:

> 2006. 10. 25, szerda keltezéssel 10.56-kor Aaron Griffin ezt írta:
> > On 10/25/06, Piche, Kevin <[hidden email]> 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 (Роман Кирилич)
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Christian Hamar alias krix

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



_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Roman Kyrylych
2006/10/25, Christian Hamar alias krix <[hidden email]>:

> > 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 (Роман Кирилич)
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/25/06, Roman Kyrylych <[hidden email]> wrote:

> 2006/10/25, Christian Hamar alias krix <[hidden email]>:
> > > 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

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Roman Kyrylych
2006/10/25, Aaron Griffin <[hidden email]>:
> 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 (Роман Кирилич)
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/26/06, Roman Kyrylych <[hidden email]> wrote:
> 2006/10/25, Aaron Griffin <[hidden email]>:
> > 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)

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Roman Kyrylych
2006/10/26, Aaron Griffin <[hidden email]>:
> 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 (Роман Кирилич)
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/26/06, Roman Kyrylych <[hidden email]> wrote:

> 2006/10/26, Aaron Griffin <[hidden email]>:
> > 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)

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Roman Kyrylych
2006/10/26, Aaron Griffin <[hidden email]>:

> > 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 (Роман Кирилич)
_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Jürgen Hötzel
In reply to this post by Aaron Griffin
On Thu, Oct 26, 2006 at 03:45:14PM -0500, Aaron Griffin wrote:

> On 10/26/06, Roman Kyrylych <[hidden email]> wrote:
> > 2006/10/26, Aaron Griffin <[hidden email]>:
> > > 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

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Kevin Piche
In reply to this post by Aaron Griffin
On Wed, 2006-10-25 at 10:56 -0500, Aaron Griffin wrote:

> On 10/25/06, Piche, Kevin <[hidden email]> 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
> [hidden email]
> 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 <log_progress>
(gdb) fin
Run till exit from #0  FtpAccess (path=0x7742a0
"vim-7.0.118-1.pkg.tar.gz",
    typ=3, mode=73, nControl=0x777810, nData=0x7fff3c50d3c8) at
ftplib.c:805
0x000000000041e298 in 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=<value optimized out>) at ftplib.c:1125
1125            if (!FtpAccess(path, typ, mode, nControl, &nData))
Value returned is $3 = 1
(gdb) s
1127            dbuf = malloc(FTPLIB_BUFSIZ);
(gdb)
1128            if (typ == FTPLIB_FILE_WRITE)
(gdb)
1127            dbuf = malloc(FTPLIB_BUFSIZ);
(gdb)
1128            if (typ == FTPLIB_FILE_WRITE)
(gdb)
1140                    while ((l = FtpRead(dbuf, FTPLIB_BUFSIZ, nData))
> 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 <log_progress>
(gdb) s
150             if (ctl->dir == FTPLIB_WRITE)
(gdb)
154             FD_ZERO(&fd);
(gdb) print fd
$10 = {__fds_bits = {13, 7838112, 4100, 4518680, 140734205318097,
    140734205318097, 140734205318016, 4519571, 747324309664,
365072220369,
    566935683113, 8192, 8240, 140734205318096, 140734205322352,
7838112}}
(gdb) print *fd
Structure has no component named operator*.
(gdb) s
157                     FD_SET(ctl->handle,&fd);
(gdb) print fd
$11 = {__fds_bits = {0 <repeats 16 times>}}
(gdb) print ctl
$12 = (netbuf *) 0x779be0
(gdb) print ctl->handle
$13 = 14
(gdb) s
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);


...cut...  control ptr is still good.


socket_wait (ctl=0x779be0) at ftplib.c:144
144     {
(gdb)
148             if ((ctl->dir == FTPLIB_CONTROL) || (ctl->idlecb ==
NULL))
(gdb)
150             if (ctl->dir == FTPLIB_WRITE)
(gdb)
154             FD_ZERO(&fd);
(gdb)
157                     FD_SET(ctl->handle,&fd);
(gdb)
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);
(gdb)
157                     FD_SET(ctl->handle,&fd);
(gdb)
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);
(gdb)
157                     FD_SET(ctl->handle,&fd);
(gdb)
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);
(gdb)
157                     FD_SET(ctl->handle,&fd);
(gdb)
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);
(gdb)
158                     tv = ctl->idletime;
(gdb)
159                     rv = select(ctl->handle+1, rfd, wfd, NULL, &tv);
(gdb)

160                     if (rv == -1)
(gdb)
167                     else if (rv > 0)
(gdb)
173             while ((rv = ctl->idlecb(ctl, ctl->xfered,
ctl->idlearg)));
(gdb)


Now we've called our callback function. ctl is still good.


log_progress (ctl=0x779be0, xfered=5792, arg=0x7fff3c51260c) at
download.c:56
56      {
(gdb) print ctl->handle
$31 = 14
(gdb) s
73              if(config->noprogressbar || (pct == 100 && lastpct ==
100)) {
(gdb)
57              int fsz = *(int*)arg;
(gdb) s
58              int pct = ((float)(xfered+offset) / fsz) * 100;
(gdb) print fsz
$32 = 7968150
(gdb)
$33 = 7968150
(gdb) s
73              if(config->noprogressbar || (pct == 100 && lastpct ==
100)) {
(gdb)
58              int pct = ((float)(xfered+offset) / fsz) * 100;
(gdb)
73              if(config->noprogressbar || (pct == 100 && lastpct ==
100)) {
(gdb)
77              alpm_get_option(PM_OPT_CHOMP, (long *)&chomp);
(gdb)
alpm_get_option (parm=29 '\035', data=0x7fff3c50d2bc) at alpm.c:153
153     {
(gdb)
155             ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1));
(gdb)
153     {
(gdb)
155             ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1));
(gdb)
156             ASSERT(data != NULL, RET_ERR(PM_ERR_WRONG_ARGS, -1));
(gdb)
158             return(_alpm_handle_get_option(handle, parm, data));
(gdb)
159     }
(gdb)
alpm_get_option (parm=29 '\035', data=0x7fff3c50d2bc) at alpm.c:158
158             return(_alpm_handle_get_option(handle, parm, data));
(gdb)
_alpm_handle_get_option (handle=0x600560, val=29 '\035',
data=0x7fff3c50d2bc)
    at handle.c:315
315             ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1));
(gdb)
313     {
(gdb)
315             ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1));
(gdb)
317             switch(val) {
(gdb)
347                     case PM_OPT_CHOMP: *data = handle->chomp; break;
(gdb)
354     }
(gdb)
log_progress (ctl=<value optimized out>, xfered=5792,
    arg=<value optimized out>) at download.c:79
79              gettimeofday(&t1, NULL);
(gdb)
80              if(xfered+offset == fsz) {
(gdb)
83              timediff = t1.tv_sec-t.tv_sec +
(float)(t1.tv_usec-t.tv_usec) /
1000000;
(gdb)
94              } else if(timediff > 1) {
(gdb)
97                      rate = (xfered-xfered1) / (timediff * 1024);
(gdb)
99                      gettimeofday(&t, NULL);
(gdb)
97                      rate = (xfered-xfered1) / (timediff * 1024);
(gdb)
99                      gettimeofday(&t, NULL);
(gdb)
97                      rate = (xfered-xfered1) / (timediff * 1024);
(gdb)
99                      gettimeofday(&t, NULL);
(gdb)
98                      xfered1 = xfered;
(gdb)
97                      rate = (xfered-xfered1) / (timediff * 1024);
(gdb)
99                      gettimeofday(&t, NULL);
(gdb)
100                     eta_s = (fsz-(xfered+offset)) / (rate * 1024);
(gdb)
101                     eta_h = eta_s / 3600;
(gdb)
104                     eta_s -= eta_m * 60;
(gdb)
101                     eta_h = eta_s / 3600;
(gdb)
102                     eta_s -= eta_h * 3600;
(gdb)
103                     eta_m = eta_s / 60;
(gdb)
104                     eta_s -= eta_m * 60;
(gdb)
107             if(rate > 1000) {
(gdb)
110                     printf("%*s %6dK %6.1fK/s %02d:%02d:%02d [",
PM_DLFNM_LEN, sync_fnm, ((xfered+offset) / 1024), rate, eta_h, eta_m,
eta_s);
(gdb)
112             cur = (int)((maxcols-57)*pct/100);
(gdb)
113             for(i = 0; i < maxcols-57; i++) {
(gdb)
114                     if(chomp) {
(gdb)
138                             (i < cur) ? printf("#") : printf(" ");
(gdb)
113             for(i = 0; i < maxcols-57; i++) {


...cut...


113             for(i = 0; i < maxcols-57; i++) {
(gdb)
141             printf("] %3d%%\r", pct);
(gdb)
142             if(lastpct != 100 && pct == 100) {
(gdb)
147             fflush(stdout);
(gdb)
145             lastcur = cur;
(gdb)
146             lastpct = pct;
(gdb)
147             fflush(stdout);
(gdb)
vim-7.0.118-1               5K    0.0K/s 388:10:38
[                       ]   0149     }
(gdb)
socket_wait (ctl=0x0) at ftplib.c:157


We've printed our progress bar and return to socket_wait but now ctl is
NULL for some reason.  Then we die on the pointer dereference below.


157                     FD_SET(ctl->handle,&fd);
(gdb) print ctl
$41 = (netbuf *) 0x0
(gdb) print rv
$42 = 1
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
socket_wait (ctl=0x0) at ftplib.c:157
157                     FD_SET(ctl->handle,&fd);
(gdb)
cleanup (signum=11) at pacman.c:183
183     {
(gdb) where
#0  cleanup (signum=11) at pacman.c:183
#1  <signal handler called>
#2  socket_wait (ctl=0x0) at ftplib.c:157
#3  0x000000000041c68b in FtpRead (buf=0x779d60, max=8192,
nData=0x5fb860)
    at ftplib.c:880
#4  0x000000000041e2e5 in FtpXfer (
    localfile=0x7fff3c50e470
"/var/cache/pacman/pkg/vim-7.0.118-1.pkg.tar.gz.part", path=<value
optimized out>, nControl=0x777810, typ=5792,
    mode=<value optimized out>) at ftplib.c:1140
#5  0x000000000041b3a3 in _alpm_downloadfiles_forreal (
    servers=<value optimized out>,
    localpath=0x7fff3c5156b0 "/var/cache/pacman/pkg", files=0x7742d0,
    mtime1=0x0, mtime2=0x0) at server.c:368
#6  0x000000000041bade in _alpm_downloadfiles (servers=0xffffffff,
    localpath=0x0, files=0x5fb860) at server.c:137
#7  0x00000000004190e3 in _alpm_sync_commit (trans=0x6068d0,
    db_local=0x606d90, data=0x7fff3c518ad8) at sync.c:820
#8  0x00000000004136cd in _alpm_trans_commit (trans=0x6068d0,
data=0x5fb860)
    at trans.c:217
#9  0x0000000000405ea7 in pacman_sync (targets=<value optimized out>)
    at sync.c:660
#10 0x0000000000407f4e in main (argc=<value optimized out>,
    argv=0x7fff3c519e38) at pacman.c:610
(gdb)


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.

k

_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Aaron Griffin
On 10/26/06, K. Piche <[hidden email]> 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
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cvs unusable on x86_64

Kevin Piche
On Thu, 2006-10-26 at 17:20 -0500, Aaron Griffin wrote:

> On 10/26/06, K. Piche <[hidden email]> 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
> [hidden email]
> 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


_______________________________________________
pacman-dev mailing list
[hidden email]
http://www.archlinux.org/mailman/listinfo/pacman-dev
12
Loading...