WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#43498 closed defect (bug) (invalid)

PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted

Reported by: arena Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

I am posting here a ticket because i do not know if this is a bug .

Since a few days, i have regularly this error :

[:error] [pid 3408:tid 1020] [client 127.0.0.1:52320] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1441151880758559780 bytes) in ...wordpress
wp-includes
functions.php on line 5472, referer: http://127.0.0.1/wordpress/wp-admin/

always the same line, on the same file.

i need to stop/start apache to continue to use my local/dev site.

When i try to open this file with NetBeans i have this error :

"(this) file cannot be safely opened with encoding windows-1252..."

i tried to open other big files from WordPress, it also occurs on formatting.php, but not on all php files :?

hereattached screenshots of my config and the error messages

regards

Attachments (4)

config.JPG (31.2 KB) - added by arena 3 years ago.
windows config
functions.JPG (67.1 KB) - added by arena 3 years ago.
opening functions.php
formatting.JPG (63.0 KB) - added by arena 3 years ago.
opening formatting.php
wp_is_stream.JPG (37.8 KB) - added by arena 3 years ago.
function wp_is_stream

Download all attachments as: .zip

Change History (16)

@arena
3 years ago

windows config

@arena
3 years ago

opening functions.php

@arena
3 years ago

opening formatting.php

#1 @Presskopp
3 years ago

try updating PHP, I had similar issues for a while locally

#2 @SergeyBiryukov
3 years ago

  • Keywords reporter-feedback added

Hi @arena, thanks for the report!

Unfortunately, there's not much info to go from, except for a huge value for attempted allocation (1441151880758559780 bytes is 1.44 exabytes).

  • Are you using WordPress 4.9.4? wp-includes/functions.php on line 5472 is where wp_validate_boolean() is defined.
  • Are there any particular steps to reproducing the issue?

#3 follow-up: @arena
3 years ago

@SergeyBiryukov 

  • I am using trunk (see attached for function wp_is_stream() )
  • Can't tell how to reproduce this issue, seems to happen when several instances of the same WordPress are running (several ajax calls)

@arena
3 years ago

function wp_is_stream

#4 in reply to: ↑ 3 ; follow-up: @SergeyBiryukov
3 years ago

Replying to arena:

I am using trunk (see attached for function wp_is_stream() )

Thanks for the additional info! Could you see what the value of stream_get_wrappers() is?

#5 in reply to: ↑ 4 @arena
3 years ago

Replying to SergeyBiryukov:

Replying to arena:

I am using trunk (see attached for function wp_is_stream() )

Thanks for the additional info! Could you see what the value of stream_get_wrappers() is?

I just updated PHP 7.0.16 to PHP 7.1.15

Here is what "var_dump(stream_get_wrappers());" looks like (out of WP)

array(11) {
  [0]=>
  string(3) "php"
  [1]=>
  string(4) "file"
  [2]=>
  string(4) "glob"
  [3]=>
  string(4) "data"
  [4]=>
  string(4) "http"
  [5]=>
  string(3) "ftp"
  [6]=>
  string(0) ""
  [7]=>
  string(0) ""
  [8]=>
  string(5) "https"
  [9]=>
  string(4) "ftps"
  [10]=>
  string(4) "phar"
}

In WP, now i have that kind of message (appears sooner than on previous php version):

[php7:error] [pid 5840:tid 1052] [client 127.0.0.1:49883] PHP Fatal error:  Possible integer overflow in memory allocation (4 * 8319104478870268257 + 32) in ...wordpress\\wp-includes\\functions.php on line 5472

always same line ...

I am going to update to 7.2.3 to see what is happening.

Last edited 3 years ago by arena (previous) (diff)

#6 follow-up: @arena
3 years ago

So i upgraded to 7.2.3 and the fatal error disappeared

I know what is following occurs on a plugin and is not directly related to WP but may be it can help.

But i have another error :

[php7:error] [pid 2052:tid 976] [client 127.0.0.1:50008] PHP Fatal error: Uncaught Error: [] operator not supported for strings in (mypluginfile:line)
Stack trace:
# 0 \wordpress\wp-includes\class-wp-hook.php(286) : MP_AdminPage::print_styles()
# 1 \wordpress\wp-includes\class-wp-hook.php(310) : WP_Hook->apply_filters(NULL, Array)
# 2 \wordpress\wp-includes\plugin.php(465) : WP_Hook->do_action(Array)
# 3 \wordpress\wp-admin\admin-header.php(113) : do_action('admin_print_sty...')
# 4 \wordpress\wp-admin\admin.php(230) : require_once('D:\webserver\Do...')
# 5 {main} thrown in (mypluginfile) on line (line), referer: http://127.0.0.1/wordpress/wp-admin/

My analysis is this :

from PHP 5 to PHP 7, PHP becomes more strict on variable types. A string remains a string, an array remains an array ...

The issue is that do_action() uses apply_filters(), which initialize by default an argument ($args) => var_dump => string(0) ""

do_action() should not pass any argument if not required.

In a plugin, in a parent class, i am using this line :

add_action('admin_print_styles',         array('MP_AdminPage', 'print_styles'));    /* xref.mailpress.org/nav.html?mp-includes/class/MP_adminpage_.class.php.source.html#l16 */

i define the print_styles() function as

public static function print_styles($styles = array())                          /* xref.mailpress.org/nav.html?mp-includes/class/MP_adminpage_.class.php.source.html#l76 */

and (for code consistancy) the same print_styles() function in the sub class as

public static function print_styles($styles = array())  {                   /*  xref.mailpress.org/nav.html?mp-admin/mails.php.source.html#l60 */
/* some code here */
parent::print_styles($styles);
}
Last edited 3 years ago by arena (previous) (diff)

#7 @arena
3 years ago

for the record,

in wp-includes/plugin.php line 405

function add_action( $tag, $function_to_add, $priority = 10, $accepted_args = 1 )

So there is by default one arg which is a string with value : ""

#8 @SergeyBiryukov
3 years ago

  • Keywords reporter-feedback removed

#9 in reply to: ↑ 6 @dd32
3 years ago

Replying to arena:

The issue is that do_action() uses apply_filters(), which initialize by default an argument ($args) => var_dump => string(0) ""

do_action() should not pass any argument if not required.

See #14881 - Unfortunately removing this would cause 10 years of back-compat issues.

If you have an action to hook, and don't intend for it to receive a parameter, but it has a default value for it's first argument, pass 0 as the number of $accepted_args.

If the root cause of this ticket is do_action() passing an empty string by default, unfortunately this is a duplicate of #14881 and it's not something that will be fixed/changed in WordPress.

Last edited 3 years ago by dd32 (previous) (diff)

#10 @arena
3 years ago

  • Resolution set to invalid
  • Status changed from new to closed

#11 @ocean90
3 years ago

  • Milestone Awaiting Review deleted
  • Version trunk deleted
Note: See TracTickets for help on using tickets.