[ut2004] 64 bit client problems with downloads

[Jeff Woods]

Look! Up in the sky!

It's a struct! It's an array!

It's BACK-SEAT CODERMAN!

More powerful than an overloaded function! Faster than an improved bubble sort! Able to malloc tall heaps in a single bound!

BACK-SEAT CODERMAN! Debugging your programs from afar... FOR GREAT JUSTICE!


On Sat, 20 Nov 2004 15:10:46 -0800
Tom Emerson <osnut at pacbell.net> wrote:

> On Friday 19 November 2004 10:09 pm, Ryan C. Gordon wrote:
> > There's a lot more involved than just reading bytes from a socket [...]
> 
> > [...] it's both inaccurate and impolite to show up and tell someone
> > that their bugs aren't "rocket science". [...]
> 
> Well, it wasn't my intention to be rude, but from what you're saying it sounds 
> like it is a problem of perception -- namely, mine :)  
> 
> I perceive a "percentage complete" calculation to be relatively simple, and 
> that debugging it would take no more effort than to set a breakpoint on the 
> final result > 100.0 and "take a look" at the underlying variables at that 
> point, then backtrack to find out why they are incorrect.  Either the 
> calculation is incorrect or the values passed to the routine are bogus.  I 
> find it hard to imagine how the calculation would be "wrong", so that leaves 
> incorrect inputs [the "GIGO" principle]
> 
> What I gather you're saying is that figuring out why the numbers passed to the 
> routine are "wrong" is a bit harder than merely inspecting memory -- this is 
> just a guess, but perhaps you are passing a 32-bit pointer to a routine that 
> internally uses a 64-bit pointer and "whatever" resides in memory just prior 
> to the pointer doesn't cause the treated-as-64-bit pointer to point outside 
> of allocated memory.  [if it did, well, you'd have caught that a long time 
> ago I'd imagine ;) ]  Of course, the fact that the routine is using a 64-bit 
> pointer could be totally unexpected because when compiled for 32 bits, it 
> would be using a 32-bit pointer "as expected", and the program wouldn't 
> exhibit the incorrect behavior.
> 
> The other point to this thread is "why does this bug exist in the first 
> place?"  An accountant once told me "if you're off by a penny, you might as 
> well be off by a million dollars" -- the fact that the program reaches 100% 
> AND THEN STARTS OVER should have been a "red flag" for the whole download 
> process -- something is causing the program to retry the download EVERY TIME, 
> and it may be as simple as forgetting to "close" the file initially 
> downloaded, so it "never" validates properly from the redirected host/server 
> (yeah, I'm guessing again :) but so long as I'm guessing, if it is indeed 
> related to whether or not the file is "closed" properly, perhaps there is a 
> race condition where you [or the "virtual machine"] believe the file to be 
> closed, but the "real" machine hasn't done that yet...)
>