Re: [Pan-devel] Download time/size estimate broken/negative Was: I need to check and/or request three features

[Rob]

Sorry for the top-post.  yahoo mail does it by default and I'm not sure it can 
be changed.

re: pan and OS versions

Fedora 19 x64
pan 0.139
gmime 2.6.19

The overflow problem occurs with less than 2GB as well.  I see it with just a 
few hundred MB of RAR downloads too.  The only time it does NOT have the 
problem is when I use the NZB import function.  In that case it seems to work 
as expected.

Thanks!

--------------------------------------------
On Thu, 7/31/14, Duncan <address@hidden> wrote:

 Subject: [Pan-devel] Download time/size estimate broken/negative Was: I need 
to check and/or request three features
 To: address@hidden
 Date: Thursday, July 31, 2014, 9:30 PM
 
 Rob posted on Thu, 31 Jul 2014
 08:52:30 -0700 as excerpted:
 
 > and while we are on the subject of PAN problems,
 sometime a few months
 > back the estimated download time and size display
 became broken,
 > displaying wildly errratic and sometime huge negative
 numbers in the
 > display.  Grab 100 or so RAR files and block save
 them.  Then add 100 or
 > so more to the queue while processing the first
 batch.  You should see
 > really bogus values on the download status
 window.  Thing is, this used
 > to work flawlessly, but now does not...and I cannot
 trace it to a change
 > in PAN itself, but possibly a change in a third party
 support library?
 
 That sounds like a signed/unsigned long-int bug, with sizes
 overflowing 
 into the signed-bit.  Are you perhaps running 32-bit
 pan and regularly 
 queuing for download > 2 GiB worth at a time?
 
 64-bit long-long-ints shouldn't be running into that issue
 yet (and for 
 several more years anyway =:^), so if it's happening with
 64-bit pan (and 
 thus 64-bit libs), it's either something else or we've a
 rather 
 interesting bug indeed, but queuing 2+ GiB of downloads and
 triggering a 
 signed-int-overflow bug on 32-bit is very possible, even
 likely if the 
 code hasn't been adjusted for that possibility yet, and that
 would 
 explain why this is the first report of it I've seen on the
 pan lists as 
 well, since I'd guess most users are 64-bit these days, at
 least those 
 doing serious binary downloading.
 
 And in addition to 32-bit/64-bit, what distro are you
 running, and are 
 you building pan yourself (from git or tarball) or using the
 distro 
 supplied version?  And while I've not verified, I'm
 guessing that would 
 be gmime functionality, so what version(s) of gmime/libgmime
 are you 
 running and distro-supplied or self-built?
 
 (For comparison, tho I don't do too much with binaries and
 likely 
 wouldn't have seen this bug, here's that info for me:
 
 Gentoo/~amd64 so 64-bit, pan built from live-git from the
 commit visible 
 in my headers since I'm posting with it via gmane,
 gmime-2.6.20 from 
 gentoo.)
 
 -- 
 Duncan - List replies preferred.   No HTML
 msgs.
 "Every nonfree program has a lord, a master --
 and if you use the program, he is your master." 
 Richard Stallman
 
 
 _______________________________________________
 Pan-devel mailing list
 address@hidden
 https://lists.nongnu.org/mailman/listinfo/pan-devel