Summary

Whilst viewing the following post (see below) I noticed that the included animated gif wasn't displaying (at the time of originally viewing this image, I was presented with a broken image icon and placeholder, which then was rendered to the Minds lightbulb image).

On further investigation, I found the following error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13989992 bytes) in /var/www/Minds/engine/Controllers/fs/v1/thumbnail.php on line 51

This error suggests that there is a maximum allowable image file size of 13.98MB (decimal - base 10 standard) / 13.34 MiB (IEC binary - base 2 standard). According to the above error, it seems that the original image has a file size that amounts to just over 134MB (128MiB).

Strangely, it seems that several other users can view the animated gif and there has only been one other user that has reported having a similar experience as myself (reported this issue within a comment which was added to the post).

So considering that this issue seems to be effecting only a minority of users, I am very intrigued and would like to gain a better understanding of what is causing this issue (I am wondering if this has something to do with either the end-users ISP provisions and / or Minds CDN provisions).

Steps to reproduce

If the image within the following post is not being displayed correctly then using Mozilla Firefox (or a Firefox derivative / Quantum rendering engine based browser) or Chromium (or Chromium derivative / Blink rendering engine based browser), view the resulting modal box (which should result in displaying the spinning "loading" wheel within the modal dialog box) then right click on the resulting rendering ("loading" image) and select the "view image" (Firefox) or "open image in new tab" (Chromium) menu item.

Platform information

Seems to be end-user platform neutral. Checked using x86_64bit versions of Mozilla Firefox (version 69.0.1 - Quantum rendering engine), Chromium (version 77.0.3865.90 - Blink rendering engine) and Midora (version 9.0 - Webkit rendering engine)

What is the current bug behavior?

See above

What is the expected correct behavior?

Animated Gif should be correctly displaying.

Relevant logs and/or screenshots

See above for error message.

Reference:

• Original Post (also see the comments which I added within the @Perennial_Plant_YaMon / Tim Berrrrr comment thread)
  https://www.minds.com/newsfeed/1040311506174717952

• Corresponding Media File
  https://www.minds.com/media/1033911929074921472

changed the description

changed the description

added scoped labels

added scoped labels and automatically removed labels

I am encountering the same issue.

Device: Note 10+ Browser: Chrome 78.0.3904.96

Placeholder is Minds Lightbulb, however drilling into the actual post it's just a black overlay.

Should have been fixed with #1120 (closed)

Can you guys try Canary later today?

And / or !397 (merged)

@benhayward.ben,
The animated GIF image that I referenced above is now being displayed within similar conditions as was used within my previous investigation, therefore I am closing this ticket.

closed

reopened

@benhayward.ben,
After testing this out with the following image that @luculent provided (which is an animated GIF that equates to 39.91MiB / 41.84MB), I noticed that whilst the file is uploading, the cached version is displayed but when completed, the image disappears and results with the file not being attached to the corresponding post (I have tested this via the same versions of Firefox and Chromium that I mentioned within this ticket's body).

Considering this issue, I have reopened this ticket and the issue needs further examining.Also due to the size restrictions that are imposed by Gitlab's issue section (which allows a maximum of 10MiB), I am providing a URL to the image file (plus a compressed .tar.gz which also contain the image file) for further testing purposes (btw, I tried compressing the file for the purpose of uploading to Gitlab using several compression techniques but due to the fact that the image file is fairly well optimised already, it wasn't compressing to a that much of a suitable size).

Reference:

• https://www.mcosi.org/cloud/index.php/s/long-pour-final

mentioned in issue minds#913 (closed)

@gthouret is this related to the above merge requests?

The root cause is us passing the entire contents of the media file as a var instead of passing a file handle. This runs through multiple call layers so not a straightforward fix.

The specific case of hitting process memory limit in the issue description has been resolved by only passing the file header to finfo not the entire file contents.

After I fixed that I was able to upload files in excess of 100M without getting that error.

If this is a live issue still you should be able to pull the logs for the failure.

The only other upload related issue I know of is hard memory limits on the containers. PHP uploads files to /tmp which by default is tmpfs in our containers - i.e. memory. An image upload generates two copies of an image in /tmp. Only when the HTTP request ends does the PHP process clean these up.

If something happens and that process can not clean up (i.e. SIGKILL because we hit the hard limit) those tmp files get left, increasing the likelihood that the next file upload request will also received a SIGKILL compounding the issue.

Is there anything you need me to do?