|  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: 2021-04-30 16:18 UTC
Avg. Score:4.4 ± 0.9
Reproduced:13 of 13 (100.0%)
Same Version:3 (23.1%)
Same OS:1 (7.7%)
From: chris at easynethk dot com Assigned: ramsey (profile)
Status: Assigned Package: uploadprogress (PECL)
PHP Version: 5.3.6 OS: CentOS 5.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: chris at easynethk dot com
New email:
PHP Version: OS:


 [2011-08-31 04:09 UTC] chris at easynethk dot com
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.


Add a Patch

Pull Requests

Add a Pull Request


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]
assign the 250 USD to author.  :)
 [2011-10-24 02:37 UTC]
-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]
may be due to the read_byte variable in 

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

 [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 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 
 [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:
 [2013-07-11 11:47 UTC] peter at kahn dot nu
This bug is still present in uploadprogress

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

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

$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
Those changes almost makes everything work. The uploadprogress gets reported properly. But as soon as the upload reaches > 2gb:


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:


and then keeps counting. Then after the size goes over 4gb the uploaded value changes randomly again. Not sure why.
 [2017-10-24 07:23 UTC]
-Status: Assigned +Status: Open -Assigned To: chregu +Assigned To:
 [2017-10-24 09:01 UTC]
-Status: Open +Status: Suspended
 [2017-10-24 09:01 UTC]
This package has not had any releases for 6 years, so I'm gonna suspend it, any new maintainer that decides to pick this up can re-open this ticket.
 [2020-01-26 01:07 UTC]
-Status: Suspended +Status: Open -Assigned To: +Assigned To: ramsey
 [2021-01-21 16:59 UTC] parag292 at yahoo dot com
The latest build from the ondrej ppa is working for me. Its version 1.1.3-3 on Ubuntu Focal I think. I changed

int read_bytes;


unsigned long read_bytes;

I was able to get upload progress for a 5 GB file all the way to 100%.
 [2021-04-30 16:18 UTC]
The variable is still declared as int[1]; changing to unsigned
long would not be okay for Windows; it should likely be size_t.
But signedness issues would have to thoroughly checked.

[1] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Feb 24 06:01:29 2024 UTC