Matthew Lye wrote:
> Okay, this bug might be a bit esoteric, so I'll do my best to describe  
> it.
 
> Replication:
>       A)  In the 'Incomplete' view of 'Downloads', one may sort the  
> downloads by the number of sources.  Doing so, then
>       B)  selecting a large group of the *not currently running/host  
> queued* incomplete downloads which have at least one source, and
>       C)  using the contextual menu item 'Start Now' to start downloading  
> the items as soon as possible,

> Symptoms:     
>       1)  I tend to notice a large number of assertion failures regarding "! 
> DOWNLOAD_IS_RUNNING(d)" from 'downloads.c'  (the main one).

This is potentially simply caused by lack of a GUI-side condition check. The
actions on files are applied to all its sources ("downloads") - where this
makes sense. The same functions are also called internally by the download
logic. If the warnings are caused by internal calls, it might be a real bug.
If it's caused by the GUI not checking some conditions, it's probably not
really a bug, just a bit ugly.

>       2)  With a bit of poking, I've found that this is due to *d->status =  
> GTA_DL_CONNECTING,
>       3)  allegedly to [unique enough] hosts with an IP number but no  
> vendor/version identity.
>       3)  Other responses have been tested and found for authentically in- 
> use downloads;  furthermore,

Broken record record? 

>       4)  the number of connections does not appear to substantiate the  
> claim that connections are being made.

Some actions, especially "start now", sometimes fail without a clear indication
why i.e., there are some conditions preventing it to be applied but the
reason is not fed back to the GUI. The only thing you can do here is to
enable debug messages, maybe add some tracing messages and then see whether
there's some real bug or if there isn't a good reason the request is ignored.
This reason should of course be reflected in the download status then.

> Analysis:
>       a)  I have traced this back as far and as best I can, and I believe  
> that the problem has to do with the status information attached to  
> incomplete files,
>       b)  but then I hit callbacks written with #define statements, et  
> cetera, and can has cheezburgr.

NOM NOM NOM

-- 
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to