WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#13847 closed defect (bug) (fixed)

WP increasing the memory above other server limit

Reported by: priitsalumaa Owned by: westi
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

Hi, I discovered a following problem:

I'm trying out the WP 3.0RC2 (no additional plugins or themes) and the admin dashboard breaks. Namely, the following menu items display a blank page under wp-admin:

  • Links->Links
  • Links->Link Categories
  • Appearance->Menus
  • Users

It seems to be caused by problems with heap overflow (and maybe WP increasing the memory above the limit set for PHP (it's 64MB)).

Examples from Appache error log:

[Fri Jun 11 13:11:49 2010] [error] [client 90.190.xxx.xxx] ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '90.190.xxx.xxx', file '/var/www/www.xxxxx.ee/wp-admin/admin.php', line 96), referer: http://www.xxxxx.ee/wp-admin/
[Fri Jun 11 13:11:49 2010] [error] [client 90.190.xxx.xxx] ALERT - canary mismatch on efree() - heap overflow detected (attacker '90.190.xxx.xxx', file '/var/www/www.xxxxx.ee/wp-admin/includes/template.php', line 3557), referer: http://www.xxxxx.ee/wp-admin/

[Fri Jun 11 13:12:16 2010] [error] [client 90.190.xxx.xxx] ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '90.190.xxx.xxx', file '/var/www/www.xxxxx.ee/wp-admin/admin.php', line 96), referer: http://www.xxxxx.ee/wp-admin/link-manager.php
[Fri Jun 11 13:12:16 2010] [error] [client 90.190.xxx.xxx] ALERT - canary mismatch on efree() - heap overflow detected (attacker '90.190.xxx.xxx', file '/var/www/www.xxxxx.ee/wp-admin/includes/template.php', line 3557), referer: http://www.xxxxx.ee/wp-admin/link-manager.php

[Fri Jun 11 13:12:23 2010] [error] [client 90.190.xxx.xxx] ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '90.190.xxx.xxx', file '/var/www/www.xxxxx.ee/wp-admin/admin.php', line 96), referer: http://www.xxxxx.ee/wp-admin/index.php

The same errors are reported when I use the nightly build.

If the memory limit is increased to 256M for PHP the "ALERT - script tried to increase memory_limit" errors dissapear from the log, but the "ALERT - canary mismatch on efree() - heap overflow detected" remain. The menus are still broken in wp-admin environment.

My questions hereby are:

  • For memory increase related error messages - is there any solution to this, which does not require increasing the memory limit of the server?

Cheers,
Priit Salumaa

Attachments (7)

13847.patch (3.5 KB) - added by hakre 4 years ago.
Use Constant instead of Magic Number
13847.2.diff (1.4 KB) - added by wpmuguru 3 years ago.
apply the admin_memory_limit filter throughout wp-admin
13847.2.patch (3.4 KB) - added by hakre 3 years ago.
13847.patch refreshed against current trunk
13847.3.patch (3.5 KB) - added by hakre 3 years ago.
with admin_memory_filter in all admin includes and constants, refreshed against trunk
13847.4.patch (3.6 KB) - added by hakre 3 years ago.
Missing filter for media.php - image_memory_limit
13847.5.patch (2.0 KB) - added by hakre 3 years ago.
Same patch with the magic number '256M' but w/o the WP_MAX_MEMORY_LIMIT constant.
13847.6.patch (2.0 KB) - added by hakre 3 years ago.
Fixed 13847.5.patch

Download all attachments as: .zip

Change History (42)

comment:1 wpmuguru4 years ago

  • Keywords heap overflow removed
  • Summary changed from canary mismatch on efree() - heap overflow to WP increasing the memory above other server limit

The issue is WP attempting to increase the memory limit above another server imposed limit:

"script tried to increase memory_limit to 268435456 bytes which is above the allowed value"

comment:2 nacin4 years ago

  • Keywords reporter-feedback added

We increase the memory limit in the admin area to 256M now. This is error-suppressed and also has a filter you can adjust: admin_memory_limit.

We bumped to 256M in other places previously, when we specifically needed it, so this is not without precedent.

comment:3 nacin4 years ago

  • Priority changed from high to normal
  • Severity changed from blocker to normal

comment:4 follow-up: westi4 years ago

  • Keywords close added
  • Owner set to westi
  • Status changed from new to accepted

For the memory limit messages you can use the filter to stop us trying to raise it that high.

For the suhosin errors these hi-light a bug in the php interpreter or a php extension you have installed not a bug in WordPress itself.

I guess you may be running with incompatible php extensions or esoteric ones.

Are you using self built php or a distribution built one?
Which host operating system and what version of php/suhosin?

comment:5 in reply to: ↑ 4 priitsalumaa4 years ago

Memory limit messages are just annoying not a real problem - increasing the PHP memory took care of them anyway.

The heap problem is an issue, though.

The WP 2.9.2 runs without any problems on the server.

Since I'm not the admin of the server and can't reach the guy during weekend I can't answer that question with certainty: "Are you using self built php or a distribution built one?" Neither can I prove or dismiss this suggestion: "I guess you may be running with incompatible php extensions or esoteric ones." - although I don't think neiter is the case.

I could find out the following things, though, maybe this helps:

$ uname
Linux

$ uname -r
2.6.27.45-server-1mnb

$ php -v
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 15 2010 11:32:10)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

$ mysql -v
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is
Server version: 5.0.89 Mandriva Linux - MySQL Standard Edition (GPL)

Cheers,
Priit

Replying to westi:

For the memory limit messages you can use the filter to stop us trying to raise it that high.

For the suhosin errors these hi-light a bug in the php interpreter or a php extension you have installed not a bug in WordPress itself.

I guess you may be running with incompatible php extensions or esoteric ones.

Are you using self built php or a distribution built one?
Which host operating system and what version of php/suhosin?

comment:6 westi4 years ago

  • Milestone changed from 3.0 to 3.1

PHP 5.2.6 was released on 01-May-2008 so in all likelihood you are using a self compiled php.

Moving out of 3.0 into 3.1 to wait for more reproductive information and confirmation that the error being triggered here is not caused by incompatible php modules in your install.

comment:7 priitsalumaa4 years ago

I'm not sure if I will find the time to debug it further - it was easier to downgrade to 2.9.2 and to modify the theme accordingly.

comment:8 tony244 years ago

  • Cc tony24 added

comment:9 layotte4 years ago

  • Cc lew@… added

For what it's worth, I just noticed this same thing on one of my VPS's...

Jun 26 18:19:53 teleread suhosin[12017]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '71.251.209.17', file '/var/www/teleread/wp-admin/admin.php', line 96)

Server version: Apache/2.2.14 (Ubuntu)
PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) (built: Apr 9 2010 08:23:39)
Suhosins 0.9.29

I'm not confident that this is a WP issue, as much as it is just suhosin being suhosin.

Lew

comment:10 layotte4 years ago

ugh, stupid formatting... these lines should have been separated:

Server version: Apache/2.2.14 (Ubuntu)

PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) (built: Apr 9 2010 08:23:39)

Suhosins 0.9.29

comment:11 layotte4 years ago

Also, I noticed this because I've been having an issue with this server, about once a week or two it keeps going nuts and I've been needing to force reboot it.

The only things running are apache and mysql w/ a single WP3.0 install. So it might be suhosin freaking out over this too. But I still sense that it is more suhosin than it is WP.

comment:12 hakre4 years ago

I reviewed the code and in the end I tend to patch this against a constant to better deal with the 256MB magic number.

hakre4 years ago

Use Constant instead of Magic Number

comment:13 hakre4 years ago

Introducing WP_MAX_MEMORY_LIMIT replacing the current 256MB Magic Number.

Name: WP_MAX_MEMORY_LIMIT
Value: Integer, String

Description:
Set WP_MAX_MEMORY_LIMIT to configure the maximum available memory for wordpress (the PHP memory limit).

When an integer is used, the value is measured in bytes. Shorthand notation, as described in this FAQ, may also be used.

comment:14 scribu4 years ago

  • Keywords has-patch added; reporter-feedback close removed

comment:15 follow-up: Denis-de-Bernardy4 years ago

Isn't there a suhosin ini setting that allows to pull the max memory limit directly? I suspect the current patch ought to be changed in such a way that, when present, it gets used instead of a flat 256MB, along with a warning to the end user in a way or another where it's useful (i.e. upgrades and file uploads).

comment:16 in reply to: ↑ 15 hakre4 years ago

Replying to Denis-de-Bernardy:

Isn't there a suhosin ini setting that allows to pull the max memory limit directly? I suspect the current patch ought to be changed in such a way that, when present, it gets used instead of a flat 256MB, along with a warning to the end user in a way or another where it's useful (i.e. upgrades and file uploads).

Sure, my first patch is only adding a constant instead of using the magic numbers. So it address only the furthermost problem that stands in the way to enable a user to deal with the problem w/o modifying core-code.

The standard PHP Memory Setting can be read by using the ini_get() function (I assume that by proxy this will be gathering the same value suhosin is checking against) and if that set to the maximum available memory would certainly solve the problem but if so, there would be no need at all to use ini_set() all over the place because it's then assumed that the server has been already configured.

But wordpress is assuming that the server is not properly configured and therefore assumes it's the better admin by just setting this up high.

As you can see it's not trivial to find the right solution so I started by removing that flaw that is solveable right away: reducing the magic numbers to a single constant.


Related: #14425

comment:17 hakre4 years ago

Memory Related: #14245

comment:19 hakre4 years ago

Memory Related: #14889

comment:20 hakre4 years ago

I would love to see some traction in the one or other direction with this one. For the moment I would favorable something that at least offers some working configuration.

comment:21 nacin3 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Triage to Future Release

comment:22 gionn3 years ago

  • Cc gionn added

Please include the proposed patch, an hardcoded 256MB value is a waste of memory on small VPS using php-cgi, I would like to configure a small memory limit in my wp-config.php.

comment:23 hakre3 years ago

Related: #15966

comment:24 prettyboymp3 years ago

  • Cc mpretty@… added

Would love to see this get some movement. I've often run into issues where I need to boost the memory limit while running imports and the media handling constantly drops it back down to 256MB.

wpmuguru3 years ago

apply the admin_memory_limit filter throughout wp-admin

comment:25 follow-up: wpmuguru3 years ago

  • Keywords 2nd-opinion removed

comment:26 in reply to: ↑ 25 ; follow-up: hakre3 years ago

Replying to wpmuguru:

Thanks for providing a patch, it's missing wp-includes/media.php, right? Any ideas how to deal with it?


Related: #16789

comment:27 in reply to: ↑ 26 ; follow-up: wpmuguru3 years ago

Replying to hakre:

Replying to wpmuguru:

Thanks for providing a patch, it's missing wp-includes/media.php, right? Any ideas how to deal with it?

I did the patch for the wp-admin/* area. I would not expect an admin_area_ filter to be used in any of the files in wp-includes. If there is something you feel needs to be patched in wp-includes, a second patch to files in wp-includes won't interfere with the one I've uploaded above.

comment:28 in reply to: ↑ 27 ; follow-up: hakre3 years ago

Replying to wpmuguru:

Replying to hakre:

Replying to wpmuguru:

Thanks for providing a patch, it's missing wp-includes/media.php, right? Any ideas how to deal with it?

I did the patch for the wp-admin/* area. I would not expect an admin_area_ filter to be used in any of the files in wp-includes. If there is something you feel needs to be patched in wp-includes, a second patch to files in wp-includes won't interfere with the one I've uploaded above.

I have one patch provided already, probably it's usefull to combine the constants with the filter. So it's possible to configure the maximum memory allowed via wp-config.php and give plugins some flexibility as well. What do you think?

comment:29 in reply to: ↑ 28 wpmuguru3 years ago

Replying to hakre:

What do you think?

On constants in general, as far as WP is concerned, less is better. I'm primarily a plugin developer and feel that the strength of WP as a platform comes from the hook and filter system which allow for essentially an infinite number of unique installations/applications of the core codebase.

The only instances where I'm in favor of constants are

  • when they are necessary - WP_CACHE allows various types of caching to be loaded instead of the built in cache and the object cache is a prerequisite to the hook & filter system
  • when they turn on a component - WP_ALLOW_MULTISITE turns on the network screen


hakre3 years ago

13847.patch refreshed against current trunk

hakre3 years ago

with admin_memory_filter in all admin includes and constants, refreshed against trunk

hakre3 years ago

Missing filter for media.php - image_memory_limit

hakre3 years ago

Same patch with the magic number '256M' but w/o the WP_MAX_MEMORY_LIMIT constant.

hakre3 years ago

Fixed 13847.5.patch

comment:31 hakre3 years ago

Overview of patches:

The following patches are working against current trunk and are covering all memory_limit locations with the '256M' value:

  • 13847.2.patch - '256M' replaced with WP_MAX_MEMORY_LIMIT constant
  • 13847.6.patch - '256M' fully filtered through 'admin_memory_limit' and 'image_memory_limit'
  • 13847.4.patch - '256M' replaced with constant AND fully filtered (so two in one)

Using a constant will make the memory limit configure-able.

Using a filter will make the memory limit control-able by plugins.

comment:32 markjaquith3 years ago

  • Milestone changed from Future Release to 3.2

This sounds like a reasonable idea. I'd go with the .4 patch.

comment:33 lloydbudd3 years ago

+1 to .4 patch

Confirmed issue still present in trunk r17731 (3.2-bleeding) when trying to do a large import today with memory set to larger than 256M.

PHP is sure a special language when it makes it interesting to figure out whether the code is increasing or decreasing the memory.

comment:34 westi3 years ago

Agreed .4 looks like the way to go.

comment:35 westi3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [17749]) Introduce WP_MAX_MEMORY_LIMIT constant for the high memory limit we set when image processing and unzipping.
Ensure it is always filterable by plugins as well as configurable in wp-config
Fixes #13847 props hakre

Note: See TracTickets for help on using tickets.