Thread

Ok - I’ve discovered the following problems in my quest to figure out why I can’t upload large images that I was previously able to upload.

In CP Home ›  Admin ›  System Preferences ›  Security and Session Preferences:

I get the following error message if I try to select NO for XSS uploads:

Notice: unserialize() [function.unserialize]: Error at offset 840 of 3061 bytes in /hsphere/local/home/arbinshi/hidden.com/system/cp/cp.admin.php on line 1825

In CP Home ›  Admin ›  System Preferences ›  Image Resizing Preferences

If I try to change from GD2 to GD, I either get a similiar error message like from above, or it defaults back to GD2 as if I selected it, specifically.

It’s choking when it tries to unserialize the site settings array.  I just tried to replicate on my install- but I’m not triggering the error.

First thing I’d do- make sure you’re running on the very latest build.  There have been a number of small bug fixes since the release.  Latest is Build 20070627.  If you’re on the latest, I’ll have to ponder a bit.

Yep. I’m running the latest build.

Huh- searching the forums I see you’ve run into the same unserialize issue before.  Is it possible to pm me over login info?  I’d like to go in and try a few things in a test template.  If that’s doable- pm me cp url, username and password.

PM sent.

*bump*

Ok! I found the official problem with the uploads:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 11264 bytes) in /hsphere/local/home/arbinshi/removed/core/core.image_lib.php on line 1240

I removed the @‘s in front of all the statements in core.image_lib.php

So it is a memory problem. Strange that I’m encountering this now, while before in 1.5.2 I was able to upload images that were of the same approximate file size.

In 1.6 we corrected a problem where XSS Cleaning was not always being done on uploaded images and we added an additional check to prevent incorrect uploads from happening.  There are a number of IE related security problems that we are trying to prevent with uploaded files.  I suspect the checks for uploads are using this memory.  You can disable these checks, if you trust your users in the Security and Session Preferences, ‘Apply XSS Filtering to uploaded files?’.

Actually, I just reused some old code that I had that dynamically allocates memory for each image:

The following fixed the problem on my webhost.

At ~ line 1435 (I changed a couple things) I added the following:

$vals = getimagesize($path);

        $memoryNeeded = round(($vals[0] * $vals[1] * $vals['bits'] * $vals['channels'] / 8 + Pow(2, 16)) * 1.65);

        if (function_exists('memory_get_usage') && memory_get_usage() + $memoryNeeded > (integer) ini_get('memory_limit') * pow(1024, 2)) {
            ini_set('memory_limit', (integer) ini_get('memory_limit') + ceil(((memory_get_usage() + $memoryNeeded) - (integer) ini_get('memory_limit') * pow(1024, 2)) / pow(1024, 2)) . 'M');
        }

I wonder how many hosts would get cranky if we started modifying that setting dynamically.

I’ve been using that bit of code in my batch-upload plugin for Textpattern for the past 9 months and haven’t heard of any complaints relating to that function, although I’m sure it’s entirely possible that they might.

Yes, but you are one person on one host.  I am thinking of thousands of people on hundreds of hosts.

It could pose a problem for some hosts, although I imagine those that it would, may disable that functionality.

That is what Dr. Jones is suggesting as well.

Interesting thread.  Arbinshire, while I recognize that this isn’t “resolved” per se, it seems that you’ve got an adequate work around - everything working for you while we investigate further?