php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #59918 Progress for uploads > 2GB breaks (32bit issue?)
Submitted: 2011-08-31 04:09 UTC Modified: 2011-10-25 05:18 UTC
Votes:9
Avg. Score:4.3 ± 0.9
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:1 (20.0%)
From: chris at easynethk dot com Assigned: chregu
Status: Assigned Package: uploadprogress (PECL)
PHP Version: 5.3.6 OS: CentOS 5.2
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-08-31 04:09 UTC] chris at easynethk dot com
Description:
------------
Progress for uploads > 2 GB break. Even though we're using the uploadprogress on 64bit machines. Any chance you can solve this with the next update? 

Nowadays more modern browsers have the capability to upload files larger than 2GB, and this limitation should really be removed from the uploadprogress module to be ready for the future.

Feedback is highly appreciated.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-24 03:06 UTC] wilcobeekhuizen at gmail dot com
This problem also happens when uploading multiple files that are more than 2GB combined. bytes_total is negative and est_sec is sometimes a negative number and other times a positive number. Casting these numbers to an abs value (removing the negative sign) does not yield correct results.
 [2011-10-24 01:21 UTC] chris at easynethk dot com
Noone here that can supply a patch or some fix for this issue? I will PayPal 250 USD to the first person that supplies a fix :)
 [2011-10-24 02:37 UTC] laruence@php.net
assign the 250 USD to author.  :)
 [2011-10-24 02:37 UTC] laruence@php.net
-Assigned To: +Assigned To: chregu
 [2011-10-24 03:33 UTC] chris at easynethk dot com
Where is the fix, then? :)
 [2011-10-25 05:18 UTC] laruence@php.net
may be due to the read_byte variable in 
uploadprogress_php_rfc1867_file(uploadprogress.c) 

it was declared to be int,  change it to size_t might fix this problem(not sure, 
didn't test).

thanks
 [2011-12-16 00:42 UTC] dhaval at patel dot sh
This is a problem with PHP. I am using Debian 32bit with PHP 5.3.8 and see this 
problem. PHP freaks out when you try to change the post_max_size and 
upload_max_filesize greater than 2047M. Once it gets to 2048M, POSTs have 
problems. You will see errors in the logs pointing to negative numbers.

I tried to compile PHP with a patch from 
http://weblog.failure.net/archives/2011/03/uploading_files.html but the resulting 
binaries have problems POSTing even with post_max_size and upload_max_filesize 
less than 2048M.

The patch listed above supposedly works on 64bit linux. I am not sure if we can 
move to 64bit on that server so that is not an option for me.

If somebody can get this to work properly on 32bit systems, that would be 
fantastic.
 [2012-01-16 11:57 UTC] tdigby at blitzgamesstudios dot com
We have manage to remove the negative value from the number returned by the 
uploadprogress extension.

We had to make the read_byte variable an unsigned long. We found that size_t was 
on 32bits wide but thank you to laruence for the suggestion.

However, the number returned for total bytes is still way off what it should be, 
which then puts the time out by quite a bit as well. Does anyone have any idea why
this might be.
 [2012-03-18 10:26 UTC] wilcobeekhuizen at gmail dot com
Total bytes is based on content length, which is wrong with uploads > 4GB. Should be fixed in PHP 5.4 according to the release notes. See this bug:
https://bugs.php.net/bug.php?id=60205
 [2013-07-11 11:47 UTC] peter at kahn dot nu
This bug is still present in uploadprogress 1.0.3.1.

I'm running:
PHP 5.4.9-4ubuntu2.1 (cli) (built: Jun 11 2013 13:08:51)

Output from: php -r 'echo PHP_INT_MAX;'
9223372036854775807

So there shouldn't be a problem with int length.

Does anyone have any solution? Or patch or...
 [2014-01-23 06:33 UTC] dmitry at bogdanov dot by
Tested on x64.

uploadprogress.c line 216
was:
fprintf(F, "upload_id=%s\nfieldname=%s\nfilename=%s\ntime_start=%d\ntime_last=%d\nspeed_average=%d\nspeed_last=%d\nbytes_uploaded=%d\nbytes_total=%d\nfiles_uploaded=%d\nest_sec=%d\n",

must be:
fprintf(F, "upload_id=%s\nfieldname=%s\nfilename=%s\ntime_start=%d\ntime_last=%d\nspeed_average=%d\nspeed_last=%d\nbytes_uploaded=%lu\nbytes_total=%lu\nfiles_uploaded=%d\nest_sec=%d\n",

reason:
$d - signed int (-2.147.483.648 - 2.147.483.648), 2GB ~ 2.147.483.648
$lu - unsigned long
 [2014-01-23 11:30 UTC] peter at kahn dot nu
@bogdanov
Thanks!
Those changes almost makes everything work. The uploadprogress gets reported properly. But as soon as the upload reaches > 2gb:

uploadprogress_get_info();

Returns nothing. Do you have any clue on how to solve this?
 [2014-01-24 09:31 UTC] dmitry at bogdanov dot by
@peter at kahn
what php version u have?
php 5.4.3 works fine.
On php 5.3.3 I see problem with uploadprogress "e_data->content_length" because old PHP versions have a "bug" with content_length (atoi() use):
./sapi/apache2filter/sapi_apache2.c:    SG(request_info).content_length = (content_length ? atoi(content_length) : 0);
On newer version, I take a look in 5.3.27, PHP use correct atol().
also tested on php 5.3.28, works fine.
 [2014-01-24 09:51 UTC] peter at kahn dot nu
Hmm, strange.I'm using php 5.4.9 and it works up to 2gb after that the uploaded size increases to:

18446744072977470545 

and then keeps counting. Then after the size goes over 4gb the uploaded value changes randomly again. Not sure why.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Thu Apr 17 16:02:22 2014 UTC