Showstopper 1.2.0.

This bug seems to be related to the following checkin:
http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=c416dd826b1da0c5093a0dfbe001018e6ffa90ff

@grangeway, this is blocking 1.2.0 release. Will you be able to fix it or revert the change?

Cannot reproduce with a 28MB file. Are you sure your PHP memory limits are set high enough? If you don't want to raise PHP memory limits, I strongly suggest looking at a new feature I added today in 0011291... X-Sendfile

Actually, just use X-Sendfile wherever possible because it's much higher performance. For small MantisBT installations with few small file uploads it won't make much of a difference though.

So erm, can anyone reproduce this? ;/

I think so, grangeway, with version 1.2.0RC2 on a Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_ldap_userdir/1.1.11 PHP/5.2.0-8+etch13 mod_ssl/2.2.3 OpenSSL/0.9.8c.

The problem AFAIK was that the file downloads were "chunked" to (more or less) the closest 512KB chunk, i.e.: original 560KB file is downloaded as a 512KB file; or a 1600KB file is downloaded with a size of 1512KB.

Also we confirmed that the file is uploaded and saved properly to disk on the server. We don't use the database for it.

We walk-arounded it for a while with this little patch on nightly build file_download.php of feb-18:

//$chunksize = 4*131072;
$chunksize = 4*999999;

Paul: What is the significance of choosing a chunk size of 4131072? Otherwise known as: 4((2^20)/8)

I gather it's something highly technical to do with heap sizes and reading files as efficiently as possible with respect to memory allocation, paging, etc?

ejc: does that include with the latest code in trunk (see attached patch to this bug), and are you reliably able to reproduce this with any file of approxy >512kb?

Paul

Paul: I think I can reliable reproduce this with exactly this platform: mantisbt-1.2.0rc2

• http_api.php (from 18/feb nightly build)
• file_download.php (from 18/feb nightly build, patched as said in 0011153:0024454).

However, with 1.2.0 released yesterday it works fine.

May you want more tests, just ask for them.

Resolving this as it has been reported to be fixed in 1.2.0

If it's not working on a patched pre 1.2.0 release then it is likely a case of patches not being applied correctly, certain required patches missing, etc. We've made quite a few changes to file downloading since 1.2.0RC2 (where file downloads were more or less completely broken).

If you can still reproduce this problem on a fresh install of 1.2.0 (ie. not a hacked upgrade from 1.2.0RC2 by placing 1.2.0 files on top of your 1.2.0RC2 release), feel free to reopen this bug report.

I upgraded to 1.2.0 and the problem still remains
BUT
I did a lot of debugging and finally found that the problem is related
to php (5.1.6) file_get_contents() !!!!!
Running file_send_chunk with a CLI script in the last run of the while(true) loop file_get_contents crashes with a bus error on mmap().
(not logged in apache error_log :-( )

So the final solution is : system upgrade this afternoon ;-)

I'm having same problem and I'm using php 5.2.1 on redhat.
I've tried with:
$chunksize = 4*999999;

and seems to work
is this the right solution ?

I had the same problem with php 5.1.6.

I found 'child pid 24521 exit signal Bus error' in the apache log ...

In php.ini the MAX_POST_SIZE is set to 8Mo so I forced $chunksize = 810241024;

Now it's working ...