Memory issue after updating to WordPress 6.8 today related to Backtrace

[chrisblakley]

I don't know if this is something that I've hooked into with Query Monitor or if it is something caused by Query Monitor itself, but when I updated to WordPress 6.8 today, it crashed my site with a 500 error.

The error itself:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 135168 bytes) in /plugins/query-monitor/classes/Backtrace.php on line 137

Query Monitor version: 3.17.2

I've had Query Monitor enabled for years and use it heavily and never had a problem, but this was instantaneous as soon as I upgraded WordPress.

I moved the plugin folder to force it to deactivate, and then gave about 6 hours before trying to reactivate it, but the moment I reactivated it I got another 500-level error with the same debug log entry as above. So it remains deactivated on my website.

I know this is not much info to troubleshoot, so I am happy to provide anything else I am able to. Again, I've also incorporated many timings and things from my custom theme/plugins, so I am not sure if this is squarely Query Monitor or somewhere in between. I also looked through the plugin page on WP as well as here on GitHub and don't see others with this issue, so apologies if it is not entirely within Query Monitor itself.

I just tried a disposable install of WordPress 6.8 and no problems with Query Monitor there. I tried deactivating all other plugins on my website and re-activated Query Monitor and got the 500 error. I also tried changing to the default Twenty TwentyFive theme and reactivating Query Monitor and also got the 500 error.

Happy to check anything else if it would help either of us identify what is causing this. Thank you.

Some more info about my server:

• WordPress 6.8
• Query Monitor 3.17.2
• Apache server
• PHP 8.2.28
• Memory limit is set to 256M
• The theme I am using is my own "Nebula" theme which is using a Child theme.

---

Some meager attempts at getting more clues here:

One more additional point if it helps at all, I tried running this with Query Monitor deactivated and the result was a count of only 8.

$trace = debug_backtrace(0);
var_dump(count($trace)); //-> 8

Counting the backtrace frames with Query Monitor on (before it crashes) it appears there are 10-24. This may not actually be the case: see additional information below.

The following tests were performed with Query Monitor activated and modifying the __construct function and running it until it (immediately) crashes.

When I add a debug log entry just before and another one just after the debug_backtrace() call, both entries appear in the debug.log many, many times– in many groups of my timezone as well as many groups of UTC timezone– there are several hundred of these entries. Example (this was all from one page load that 500 errored– there were about 300 of these entries):

I logged a summary of each backtrace frame that was occurring until the site crashed and it produced a 43mb debug.log file with 386,000 lines haha. There were only 208 "groups" of entries (which was interesting because that means the average number of frames was nearly 2,000). One particular group that was 3,779 frames itself was repeated many, many times. Within that group was the following pattern of about 15 lines repeated over and over:

/wp-includes/plugin.php:205 — WP_Hook->apply_filters()
/wp-includes/functions.php:6023 — apply_filters()
/wp-includes/l10n.php:1371 — _doing_it_wrong()
/wp-includes/l10n.php:1409 — _load_textdomain_just_in_time()
/wp-includes/l10n.php:195 — get_translations_for_domain()
/wp-includes/l10n.php:307 — translate()
/wp-content/plugins/query-monitor/classes/Util.php:246 — __()
/wp-content/plugins/query-monitor/classes/Backtrace.php:340 — QM_Util::get_file_component()
/wp-content/plugins/query-monitor/classes/Backtrace.php:271 — QM_Backtrace::get_frame_component()
/wp-content/plugins/query-monitor/collectors/caps.php:156 — QM_Backtrace->get_component()
/wp-includes/class-wp-hook.php:326 — QM_Collector_Caps->filter_user_has_cap()
/wp-includes/plugin.php:205 — WP_Hook->apply_filters()
/wp-includes/class-wp-user.php:815 — apply_filters()
/wp-includes/capabilities.php:1018 — WP_User->has_cap()
/wp-content/plugins/query-monitor/classes/QueryMonitor.php:121 — user_can()
/wp-includes/class-wp-hook.php:324 — QueryMonitor->filter_user_has_cap()
/wp-includes/plugin.php:205 — WP_Hook->apply_filters()
/wp-includes/class-wp-user.php:815 — apply_filters()
/wp-includes/capabilities.php:1018 — WP_User->has_cap()
/wp-includes/capabilities.php:911 — user_can()
/wp-content/plugins/query-monitor/collectors/doing_it_wrong.php:97 — current_user_can()

(and just for reference to show how that group was repeating hundreds of times):

[qvarting]

I got the same issue when updating to 6.8

[Supportic]

I got the same issue running on 6.8 First I thought it had something to do with xdebug because it detected an infinite loop but after removing xdebug completely I still get this issue. (docker environment)

[chrisblakley]

As a temporary fix, disabling the Query Monitor Capabilities Panel prevents the fatal error.

Add this to wp-config.php:

define('QM_ENABLE_CAPS_PANEL', false);