HHVM bug causes issues with piwigo #445

New Issue

2026-10-04T23:59:00+02:00

adam commented

2026-10-04 23:59:00 +02:00

http://i.imgur.com/JRBGS3u.png
This issue happens when using hhvm's fastcgi with nginx
The proposed temp fix from hhvm is to replace all instances that try to retrieve upload_max_file_size with ini_get('hhvm.server.upload.upload_max_file_size');

http://i.imgur.com/JRBGS3u.png This issue happens when using hhvm's fastcgi with nginx The proposed temp fix from hhvm is to replace all instances that try to retrieve upload_max_file_size with ini_get('hhvm.server.upload.upload_max_file_size');

adam closed this issue

2026-10-04 23:59:00 +02:00

adam commented

2026-10-04 23:59:01 +02:00

if you could be more specific that may help us to answer you

if you could be more specific that may help us to answer you

adam commented

2026-10-04 23:59:02 +02:00

Well Not only does the warning in the image show up when using HHVM but images that are uploaded actually never get uploaded but are still added to the database with broken images.

Well Not only does the warning in the image show up when using HHVM but images that are uploaded actually never get uploaded but are still added to the database with broken images.

adam commented

2026-10-04 23:59:02 +02:00

An example would be this http://pic.ilp.moe/picture.php?/3787/category/4 As you can see the image is clearly broken even though i just uploaded it.

An example would be this http://pic.ilp.moe/picture.php?/3787/category/4 As you can see the image is clearly broken even though i just uploaded it.

adam commented

2026-10-04 23:59:03 +02:00

HHVM just as in HipHop Virtual Machine? please gives more détails about your environnement and what things goes wrong!!
please search on our website/google and report on our forum
For instance take a deep look at http://piwigo.org/doc/doku.php?id=user_documentation:faq:pictures_missing
then we will decide to open a bug ticket
Thank you

HHVM just as in HipHop Virtual Machine? please gives more détails about your environnement and what things goes wrong!! please search on our website/google and report on our forum For instance take a deep look at http://piwigo.org/doc/doku.php?id=user_documentation:faq:pictures_missing then we will decide to open a bug ticket Thank you

adam commented

2026-10-04 23:59:04 +02:00

HipHop VM 3.13.1 (rel)
Compiler: tags/HHVM-3.13.1-0-g4f382ad928a6e2a0607a8dcb251002aca77f11f6
Repo schema: 655b5912cb8136e9df6f9be972153e38ac446e0f

nginx version: nginx/1.9.3 (Ubuntu)

mysqladmin  Ver 8.42 Distrib 5.6.28, for debian-linux-gnu on x86_64

mysql  Ver 14.14 Distrib 5.6.28, for debian-linux-gnu (x86_64) using  EditLine wrapper

I am running Ubuntu wily 64 on a Dedicated server with 6 cores, 24GB of ram and 2TB of HDD space.
I use hhvm in fastcgi mode with nginx as the front and mysql for the database.

Uploading Any images since switching from php5 to hhvm is COMPLETELY BROKEN
The max_upload_filesize is one thing i have mentioned 3 times now.
I'm not really sure what else to say. There are no errors during upload http://i.imgur.com/DSToHcy.png

Tried following the FAQ http://i.imgur.com/VGl6I0Y.png However there was no _data/tmp/i.log so

Also to note The Original image is also broken as well. So its not just that thumbnails aren't generated properly its also that piwigo is completely rejecting images but still placing their info in the database as if they were uploaded.

@flop25 @plegall

``` HipHop VM 3.13.1 (rel) Compiler: tags/HHVM-3.13.1-0-g4f382ad928a6e2a0607a8dcb251002aca77f11f6 Repo schema: 655b5912cb8136e9df6f9be972153e38ac446e0f nginx version: nginx/1.9.3 (Ubuntu) mysqladmin Ver 8.42 Distrib 5.6.28, for debian-linux-gnu on x86_64 mysql Ver 14.14 Distrib 5.6.28, for debian-linux-gnu (x86_64) using EditLine wrapper ``` I am running Ubuntu wily 64 on a Dedicated server with 6 cores, 24GB of ram and 2TB of HDD space. I use hhvm in fastcgi mode with nginx as the front and mysql for the database. Uploading Any images since switching from php5 to hhvm is COMPLETELY BROKEN The max_upload_filesize is one thing i have mentioned 3 times now. I'm not really sure what else to say. There are no errors during upload http://i.imgur.com/DSToHcy.png Tried following the FAQ http://i.imgur.com/VGl6I0Y.png However there was no _data/tmp/i.log so Also to note The Original image is also broken as well. So its not just that thumbnails aren't generated properly its also that piwigo is completely rejecting images but still placing their info in the database as if they were uploaded. @flop25 @plegall

adam commented

2026-10-04 23:59:05 +02:00

I will be testing tommorow's nightly build for hhvm to see if this issue still exists. If it doesn't i'll close this issue.

I will be testing tommorow's nightly build for hhvm to see if this issue still exists. If it doesn't i'll close this issue.

adam commented

2026-10-04 23:59:05 +02:00

@flop25 @plegall issue still not fixed also http://piwigo.org/doc/doku.php?id=user_documentation:faq:pictures_missing the log path _data/tmp/i.log is wrong as i have a bunch of log files in _data/logs/ although no errors just a bunch of debug

@flop25 @plegall issue still not fixed also http://piwigo.org/doc/doku.php?id=user_documentation:faq:pictures_missing the log path _data/tmp/i.log is wrong as i have a bunch of log files in _data/logs/ although no errors just a bunch of debug

adam commented

2026-10-04 23:59:06 +02:00

also i recently changed to mariadb as well

Piwigo version

    Piwigo 2.8.0

Environment

    Operating system: Linux
    PHP: 5.6.99-hhvm (Show info) [2016-04-20 19:49:05]
    MySQL: 5.5.5-10.0.23-MariaDB-0ubuntu0.15.10.1 [2016-04-20 19:49:05]
    Graphics Library: ImageMagick 6.8.9-9

Database

    1982 photos (first photo added on Tuesday 5 April 2016)
    3 albums including 1 physical and 2 virtual (1982 associations)
    3 tags (1982 associations)
    5 users
    1 group
    0 comments
    no rate

also i recently changed to mariadb as well Piwigo version ``` Piwigo 2.8.0 ``` Environment ``` Operating system: Linux PHP: 5.6.99-hhvm (Show info) [2016-04-20 19:49:05] MySQL: 5.5.5-10.0.23-MariaDB-0ubuntu0.15.10.1 [2016-04-20 19:49:05] Graphics Library: ImageMagick 6.8.9-9 ``` Database ``` 1982 photos (first photo added on Tuesday 5 April 2016) 3 albums including 1 physical and 2 virtual (1982 associations) 3 tags (1982 associations) 5 users 1 group 0 comments no rate ```

adam commented

2026-10-04 23:59:07 +02:00

@flop25 @thunderrabbit @mistic100 @nikrou @patdenice @plegall For now i would strongly advise against using piwigo with hhvm (fastcgi mode) and just stick to php5 or php7.

The number of issues within that mode for hhvm is kind of rediculous imo. On top of that the issues are so bad that they completely break image uploading and various other functions of php5 (not even gonna comment on 7 because its too new and i haven't tested however im willing to bet either the same results or worse).

@flop25 @thunderrabbit @mistic100 @nikrou @patdenice @plegall For now i would strongly advise against using piwigo with hhvm (fastcgi mode) and just stick to php5 or php7. The number of issues within that mode for hhvm is kind of rediculous imo. On top of that the issues are so bad that they completely break image uploading and various other functions of php5 (not even gonna comment on 7 because its too new and i haven't tested however im willing to bet either the same results or worse).

adam commented

2026-10-04 23:59:07 +02:00

https://github.com/facebook/hhvm/issues/4993
http://stackoverflow.com/questions/33162913/wordpress-ignoring-hhvm-upload-max-file-size
https://github.com/wikimedia/mediawiki/commit/ed6648427a86d6893deb219081a96e337a1141cb

https://github.com/facebook/hhvm/issues/4993 http://stackoverflow.com/questions/33162913/wordpress-ignoring-hhvm-upload-max-file-size https://github.com/wikimedia/mediawiki/commit/ed6648427a86d6893deb219081a96e337a1141cb

adam commented

2026-10-04 23:59:08 +02:00

I'm not sure that's the cause of this issue, and all of the things you've referenced there should already have been fixed.

I'm not sure that's the cause of this issue, and all of the things you've referenced there should already have been fixed.

adam commented

2026-10-04 23:59:09 +02:00

@flop25 You linked things that have already been fixed (from what i can see although, it looks like fastcgi still has the issue). And editing the piwigo core with dirty hacks to work with hhvm shouldn't even be a thing.

@Orvid I can't pin point this issue either. The logs don't show any errors at all. Upon switching back to php5-fpm i have no issues. This only happens when using hhvm in fastcgi mode. All i know is that i get the same php message (and uploading does not work) whenever trying to upload with hhvm in fastcgi mode.

@flop25 You linked things that have already been fixed (from what i can see although, it looks like fastcgi still has the issue). And editing the piwigo core with dirty hacks to work with hhvm shouldn't even be a thing. @Orvid I can't pin point this issue either. The logs don't show any errors at all. Upon switching back to php5-fpm i have no issues. This only happens when using hhvm in fastcgi mode. All i know is that i get the same php message (and uploading does not work) whenever trying to upload with hhvm in fastcgi mode.

adam commented

2026-10-04 23:59:10 +02:00

let's be precise
1- the fact that php returns to piwigo a zero value of upload_max_file_size can't be fixed in piwigo We won't add specific ini_get for all exotic bundle. You can fork the project and create your custom version if you want. BUT before going into this @kamijoutouma should carefully check if his config is correct as I pointed with my links.

2- the fact that a null picture is uploaded might be fixed, we can check the 'validity' of picture before adding it to the database and then delete it if something is wrong. We also can forbid the upload if upload_max_file_size=0. But we need more details. " The Original image is also broken " what does that mean ? what's the file size in octet ? the permissions? if you open it as text do you see any error message in header? which logs did you checked?
Piwigo is using Plupload, maybe you can it in another script using your environnement

let's be precise 1- the fact that php returns to piwigo a zero value of upload_max_file_size can't be fixed in piwigo We won't add specific ini_get for all exotic bundle. You can fork the project and create your custom version if you want. BUT before going into this @kamijoutouma should carefully check if his config is correct as I pointed with my links. 2- the fact that a null picture is uploaded might be fixed, we can check the 'validity' of picture before adding it to the database and then delete it if something is wrong. We also can forbid the upload if upload_max_file_size=0. But we need more details. " The Original image is also broken " what does that mean ? what's the file size in octet ? the permissions? if you open it as text do you see any error message in header? which logs did you checked? Piwigo is using Plupload, maybe you can it in another script using your environnement

adam commented

2026-10-04 23:59:11 +02:00

@flop25 i checked my config and it is correct. As for the null picture i cant get it to do it anymore. Now it just doesn't upload at all so i'm not really sure what caused it in the first place. However The forever loading upload bar when trying to upload (that wont let me click cancel or anything) is definetly annoying so i do agree to the "forbidding upload if size is 0" idea.

Also tbh I don't agree to forking the project to fix and issue with a "dirty hack" so to speak. This particular issue is a problem with HHVM and using a "dirty hack" (in HHVM's users own words btw) is not the correct solution here.

Also the image dimensions were pretty normal (500x500 30kb JPG). PHP5 Has no problem uploading this image so i really don't get why hhvm is doing this. Supposedly this issue has already been fixed but the issues displayed here prove otherwise.

Not to mention (after doing a quick google search) people all over the internet are still complaining about this issue so it clearly has not been fixed.

@Orvid At this point i have to really deem HHVM as unfit for use in a production environment that uses php5. The inconsistencies between php5 and hhvm are numerous and it shows with the number of issues labeled (php5 incompatibility) on hhvm's github page.
Lets not even mention the fact that most of those issues are "still" open. If hhvm is going to say it supports php5 and then not work with basic php5 functions something is clearly wrong. I understand that these issues only appear in fast cgi mode and that facebook doesn't use that mode. However facebook really needs to pick up and fix these issues fully if they want users to keep using their library.

Now if some user wants to come along and rewrite PIWIGO in hack (hhvm's language) and it has no issues then i "might" use it.

@flop25 i checked my config and it is correct. As for the null picture i cant get it to do it anymore. Now it just doesn't upload at all so i'm not really sure what caused it in the first place. However The forever loading upload bar when trying to upload (that wont let me click cancel or anything) is definetly annoying so i do agree to the "forbidding upload if size is 0" idea. Also tbh I don't agree to forking the project to fix and issue with a "dirty hack" so to speak. This particular issue is a problem with HHVM and using a "dirty hack" (in HHVM's users own words btw) is not the correct solution here. Also the image dimensions were pretty normal (500x500 30kb JPG). PHP5 Has no problem uploading this image so i really don't get why hhvm is doing this. Supposedly this issue has already been fixed but the issues displayed here prove otherwise. Not to mention (after doing a quick google search) people all over the internet are still complaining about this issue so it clearly has not been fixed. @Orvid At this point i have to really deem HHVM as unfit for use in a production environment that uses php5. The inconsistencies between php5 and hhvm are numerous and it shows with the number of issues labeled (php5 incompatibility) on hhvm's github page. Lets not even mention the fact that most of those issues are "still" open. If hhvm is going to say it supports php5 and then not work with basic php5 functions something is clearly wrong. I understand that these issues only appear in fast cgi mode and that facebook doesn't use that mode. However facebook really needs to pick up and fix these issues fully if they want users to keep using their library. Now if some user wants to come along and rewrite PIWIGO in hack (hhvm's language) and it has no issues then i "might" use it.

adam commented

2026-10-04 23:59:12 +02:00

FastCGI mode effects nothing in HHVM other than how it serves the actual requests. You would be hitting the same issues even if serving via Proxygen. The vast majority of the issues tagged as incompatibilities are edge cases, and come from highly atypical use cases, or are things that simply haven't been implemented. The PHP5 functionality in HHVM is there, and the same functions are available in Hack as they are in PHP. If PIWIGO were written in Hack, it would still face the same issue, though I still don't know what that issue is.

As far as I can tell, the original issue in this case was that HHVM was truncating the value returned by upload_max_file_size to MB, and the value you were using was less than that, resulting in it reporting that the ini setting was 0. https://github.com/facebook/hhvm/commit/54d412d32f01207a2da74c70953b8db4e061aef7 should have fixed that issue, and I have nothing else to go on for fixing anything beyond that.

FastCGI mode effects nothing in HHVM other than how it serves the actual requests. You would be hitting the same issues even if serving via Proxygen. The vast majority of the issues tagged as incompatibilities are edge cases, and come from highly atypical use cases, or are things that simply haven't been implemented. The PHP5 functionality in HHVM is there, and the same functions are available in Hack as they are in PHP. If PIWIGO were written in Hack, it would still face the same issue, though I still don't know what that issue is. As far as I can tell, the original issue in this case was that HHVM was truncating the value returned by upload_max_file_size to MB, and the value you were using was less than that, resulting in it reporting that the ini setting was 0. https://github.com/facebook/hhvm/commit/54d412d32f01207a2da74c70953b8db4e061aef7 should have fixed that issue, and I have nothing else to go on for fixing anything beyond that.

adam commented

2026-10-04 23:59:12 +02:00

I had the value set to 2M though in the ini? The values it was showing were incorrect in the first place because the first time i didnt set it at all.

I had the value set to 2M though in the ini? The values it was showing were incorrect in the first place because the first time i didnt set it at all.

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#445