Opened 4 years ago
Closed 3 years ago
#57121 closed defect (bug) (fixed)
'get_current_user_id' in 'gettext' filter causing memory error
| Reported by: | adityaarora010196 | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.2 |
| Component: | Users | Version: | 6.1 |
| Severity: | normal | Keywords: | has-patch fixed-major |
| Cc: | Focuses: |
Description
I am trying to 'get_current_user_id' in 'gettext' filter and causing memory error.
Here is log of error:
2022/11/15 22:18:30 [error] 667958#667958: *8577 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/server/htdocs/wp-includes/class-wp-user.php on line 521
I am not sure but this code is working on WP 5.8.6
Let me know if i can help in anything...
Attachments (1)
Change History (9)
#2
@
4 years ago
- Keywords has-patch added
57121.diff appears to work, because it succeeds in setting the static $duplicated_keys array once and no longer goes into this code section on subsequent calls.
As a workaround until a fix is released, this can also be resolved by removing the filter before calling get_current_user_id() and readding it after:
function my_gettext_callback( $translation ) {
remove_filter( 'gettext', __FUNCTION__ );
$user_id = get_current_user_id();
add_filter( 'gettext', __FUNCTION__ );
return $translation;
}
add_filter( 'gettext', 'my_gettext_callback' );
#3
@
3 years ago
Writing a test for this is tricky, as wp_salt() is called via wp_create_nonce() in wp_default_scripts() and wp_default_packages_inline_scripts() as part of the general bootstrap routine before test suite initialization, so the $duplicated_keys static variable is already set and the loop cannot be triggered by a test.
#5
@
3 years ago
- Keywords fixed-major added
- Resolution fixed
- Status closed → reopened
Reopening for 6.1.2 consideration.
#6
@
3 years ago
- Milestone 6.1.2 → 6.2.1
Moving to 6.2.1, as there are no plans for 6.1.2 at this time.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Hi there, welcome to WordPress Trac! Thanks for the report.
I was able to reproduce the issue with this code:
add_filter( 'gettext', function( $translation ) { static $call_count = 0; if ( $call_count++ > 500 ) { echo implode( '<br />', array_reverse( wp_debug_backtrace_summary( null, 0, false ) ) ); die(); } $user_id = get_current_user_id(); return $translation; });which displays the following call stack:
require_once('wp-admin/admin.php') require_once('wp-load.php') require_once('S:/home/wordpress.test/develop/wp-config.php') require_once('wp-settings.php') do_action('setup_theme') WP_Hook->do_action WP_Hook->apply_filters create_initial_theme_features __ translate apply_filters('gettext') WP_Hook->apply_filters {closure} get_current_user_id wp_get_current_user _wp_get_current_user apply_filters('determine_current_user') WP_Hook->apply_filters wp_validate_auth_cookie wp_hash wp_salt __ translate apply_filters('gettext') WP_Hook->apply_filters {closure} get_current_user_id wp_get_current_user _wp_get_current_user apply_filters('determine_current_user') WP_Hook->apply_filters wp_validate_auth_cookie wp_hash wp_salt __ translate apply_filters('gettext') ...This appears to be introduced in [54249] / #55937, where a
__()function call was added towp_salt().get_current_user_id()calls thedetermine_current_userfilter, which callswp_validate_auth_cookie(), which eventually callswp_salt(), leading to an infinite loop.Moving to 6.1.2 to investigate potential options to fix this.