Last modified: 2014-10-24 22:22:17 UTC
On our wiki, we had a page that displayed several image thumbnails. After some time, one of the source images was revised by someone who uploaded a larger version of the image (a PNG). After that larger image was uploaded, both the file page and the page displaying the thumbnails ceased to load in the browser. After enabling debug data, we saw this error: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 66510592 bytes) in D:\Inetpub\wwwroot\wiki\EVA\includes\media\Bitmap.php on line 566 Upon further investigation, the revised image was 3559x4672, which seems to exceed the default value of $wqMaxImageArea. The issue was duplicated on a development server with a .png that exceeds those limits. It seems large JPGs are ignored for this. So it seems to do with the image file type. The dev server local settings were modified with the following: $wgMaxImageArea = 1.25e10; $wgMemoryLimit = 500000000; The image loaded fine after increasing these values. A second test was performed where a large PNG was modified and uploaded after local settings was modified to only increase $wgMemoryLimit, leaving $wgMaxImageArea at the default setting. This image had a pixel count that exceeded the $wgMaxImageArea, but it successfully uploaded and the thumbnail was successfully created. This seems to indicate that with additional memory allocation, the software ignored the $wgMaxImageArea setting and allowed for the upload of an excessively large image. I'm not sure if this is a bug in how $wgMaxImageArea is handled when a user attempts to upload an image larger than that value or if the documentation just needs to be improved to explain its usage.
Maybe you have the VipsScaler extension enabled?
We do not have that extension installed.
Can you share the test file?
I have duplicated this behavior with several image files. Here is one I can share: https://commons.wikimedia.org/wiki/File:Nunak.png The issue did not happen on Wikimedia Commons, but I duplicated it on our dev server. I attempted to upload the image, which exceeds 3500x3500 pixels. That resulted in a blank web page. I opened "Recent changes" for that wiki in another browser tab and saw that the file did in face upload. I then modified LocalSettings.php to increase $wgMemoryLimit to 500000000 (500M) and reattempted to open the file page. This time it opened with the scaled preview just fine. So it seems to me I should have been given some kind of message that the image I tried to upload exceeded the $wgMaxImageArea setting. Instead it just ended on a blank page.
Hmmm. Usually image scaling doesnt affect php's memory limit ver much. Are you using image magick to scale files or GD (shoild say in LocalSettings.php)
(In reply to Bawolff (Brian Wolff) from comment #5) > Hmmm. Usually image scaling doesnt affect php's memory limit ver much. Are > you using image magick to scale files or GD (shoild say in LocalSettings.php) I definitely suspect GD (aka $wgUseImageMagick = false) is the reason the memory limit is being hit (line 566 is also in the middle of GD code on 1.23.2). Your wiki is probably using it since on windows its unlikely to have image magick installed (Or even if it is, its unlikely MW will be able to automatically find it). AFAIK, GD scales stuff in the php process, so is subject to php's memory_limit (aka $wgMemoryLimit) (unlike image magick which is a separate process having a separate memory limit). Maybe we should be trying to raise the php memory limit up to $wgMaxShellMemory during the scaling process if we're using GD.
I think we're using GD. We have $wgUseImageMagick = false. I think I understand your points about GD and the associated increased memory use. I've noticed that I can increase that value. While I'm not sure how far I can safely increase that value without impacting the server, the question about the $wgMaxImageArea parameter remains: Why am I able to upload an image with pixel count in excess of that value? Upon further investigation, I discovered that the $wgMaxImageArea was actually set to a higher value in another custom settings file referenced from LocalSettings. Once I found that, I commented it out and refreshed the large image page. The result is that the scaled image preview is gone and replaced with the message "Error creating thumbnail: Invalid thumbnail parameters". If I uncomment that line to increase $wgMaxImageArea, the scaled image preview appears again. So what I think this is telling me is that the $wgMaxImageArea value does not control a max size value of an image that is allowed to be uploaded, but rather a max size of an image that will be scaled. Is that true? If so, I'd like to update the documentation for that parameter.
(In reply to Daren Welsh from comment #7) > I think we're using GD. We have $wgUseImageMagick = false. > > I think I understand your points about GD and the associated increased > memory use. I've noticed that I can increase that value. While I'm not sure > how far I can safely increase that value without impacting the server, the > question about the $wgMaxImageArea parameter remains: Why am I able to > upload an image with pixel count in excess of that value? > > > So what I think this is telling me is that the $wgMaxImageArea value does > not control a max size value of an image that is allowed to be uploaded, but > rather a max size of an image that will be scaled. Is that true? If so, I'd > like to update the documentation for that parameter. That's correct. The point is to prevent people from exploding the server, not to prevent them from uploading big files (In some situations, particularly in Wikimedia, there are use cases for having a large file be uploaded, even if it cannot be rendered). Which documentation were you reading that was misleading?
I was reading this: https://www.mediawiki.org/wiki/Manual:$wgMaxImageArea Thank you for modifying it, though I think it could use some more detail. Can you provide an example of a case where you want a large (image) file uploaded where it cannot be rendered/scaled? 1. I don't agree that you should allow a user to upload an image of a size that will not be able to be scaled by whatever tool is being used because the default action of the upload page is to take you to the file page with a scaled version of that image. So that process just breaks in the case of a large image. The upload page should stop the upload and report that the image size is in excess of the $wgMaxImageArea value which will result in memory issues when the image is automatically scaled. Maybe there should be an option or separate special page for large images where you do not require scaled versions. 2. I find the following scenario interesting: I increase the value of $wgMaxImageArea (for example, to 100,000,000) but leave $wgMemoryLimit to the default value. Then I go to the upload page to upload a new version of an image that is very large but under the new limit of $wgMaxImageArea (and $wgMaxUploadSize). After selecting the file, it creates the thumbnail successfully. But when I click on the upload button, I get a blank page. Now the only way to fix that page is to increase $wgMemoryLimit in LocalSettings (at least temporarily for that one page load). It seems like there should be some mechanism to relate these two values together. Remember, the reason I posted this report and am investigating the details is that one of our users uploaded an image with no warning or push-back and was met with two broken pages: the file page itself and a page that displayed a thumbnail of that image. It seems like there should be something in place to "more-gracefully fail".
(In reply to Daren Welsh from comment #9) > I was reading this: https://www.mediawiki.org/wiki/Manual:$wgMaxImageArea > > Thank you for modifying it, though I think it could use some more detail. > > Can you provide an example of a case where you want a large (image) file > uploaded where it cannot be rendered/scaled? > > 1. I don't agree that you should allow a user to upload an image of a size > that will not be able to be scaled by whatever tool is being used because > the default action of the upload page is to take you to the file page with a > scaled version of that image. So that process just breaks in the case of a > large image. The upload page should stop the upload and report that the > image size is in excess of the $wgMaxImageArea value which will result in > memory issues when the image is automatically scaled. Maybe there should be > an option or separate special page for large images where you do not require > scaled versions. People uploading original source files. People uploading very high resolution scans of an image from a museum, that sort of thing. Sometimes people upload files to the wiki with the sole intention of "sharing" it with the group, and don't care about thumbnailing it at all. People use MediaWiki for a wide variety of purposes. > 2. I find the following scenario interesting: I increase the value of > $wgMaxImageArea (for example, to 100,000,000) but leave $wgMemoryLimit to > the default value. Then I go to the upload page to upload a new version of > an image that is very large but under the new limit of $wgMaxImageArea (and > $wgMaxUploadSize). After selecting the file, it creates the thumbnail > successfully. Note, the preview in the upload form happens on the client side. Your web browser makes the thumbnail succesfully, not MW (Which is why the server side limits don't come into play). > But when I click on the upload button, I get a blank page. Now > the only way to fix that page is to increase $wgMemoryLimit in LocalSettings > (at least temporarily for that one page load). It seems like there should be > some mechanism to relate these two values together. I agree that that is rather bad behaviour. If using image magick you get an error message instead of a blank page (A hard to comprehend error message, but an error nonetheless). I agree that ideally the two would be related, although its kind of complicated. The amount of memory required and the size of the image are related, but is not exactly a functional link. Different images of the same size sometimes take different amount of memory, and the amount of memory taken up differs depending on what program you use to scale the image, what version of the program is in use, and possibly which platform you're running on. So its not like we can say - The area limit is foo, so the memory limit needs to be bar. Some people may also not like MW playing with memory limit, as that's meant as a stop valve for the web server to not steal all the computer's memory and cause problems for others on the server (OTOH, anyone who is seriously using the memory limit like that should be setting it in PHP config and not allowing MW to play with it). > > Remember, the reason I posted this report and am investigating the details > is that one of our users uploaded an image with no warning or push-back and > was met with two broken pages: the file page itself and a page that > displayed a thumbnail of that image. It seems like there should be something > in place to "more-gracefully fail". I agree that the failure mode here is quite sucky. Especially the blank page part.
