Memory Leaks

[Jonathan Moore]

probably, the cart is instantiated by the abandoned shopping carts which is checking in the background to see if it should send an email reminder: at this point there is no user request and no order language set, so polylang can’t detect language.

On the other hand, there is no user to choose free products, and the free product selection doesn’t appear and isn’t needed in the shopping cart reminder email, so could we ensure that the free products selection is not even called if there is no request context?

I’ll look at this some more..

[Soft79]

I see a potential infinite recursion in registerCouponStringsForTranslation of the Polylang Integration plugin.

That function is called when filter woocommerce_coupon_get__wjecf_* is fired, but may fire the same filter again because it loads coupon meta fields.

[Soft79]

Try moving the $coupons_loaded = true; to the top of the function.

[Jonathan Moore]

oddly, that change alone seemed to make things much worse…

[Soft79]

You did place it after if (! $coupons_loaded) { ?

[Jonathan Moore]

haha yes,
I’m just going to try disabling the whole module if we’re in cron.

I’m suspecting the term translations as I know Polylang did some “optimisation” on that in recent versions: where the coupon is linked to product category it’s also trying to get the category translations..

[Soft79]

The method used in registerCouponStringsForTranslation is a performance killer for sites with many coupons. I advise you to optimize this code.

[Jonathan Moore]

yes, I just added a transient for the coupons..

[Jonathan Moore]

this is a decoy, it’s also blowing up with the coupon translation module turned off, but the abandoned cart and autocoupons turned on.

[Soft79]

Your best bet would be debugging this in a testing environment. Preferably with Xdebug and/or disabling all plugins except WC and our plugin.

[Jonathan Moore]

I know what you mean – and I will – but this doesn’t happen in a test environment, or interactively
and the test environment isn’t trying to email clients about abandoned shopping carts etc etc.

[Soft79]

Another trick would be placing error_log(print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 100), true)); right before the lines that produce memory errors. For example if memory usage is high, like so if (memory_get_usage() > 100000000).

Make sure you do this only once per location per request, to prevent flooding the log.

[Jonathan Moore]

if I knew what are the lines that really produce the memory errors that could be doable.

At lot of the time it is just like:
[11-Apr-2018 18:41:45 UTC] PHP Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/plugin.php on line 449

In these cases the failure to allocate 20480 bytes is a symptom of something having eaten all the memory, not the cause.

It all stops though when WJECF_AutoCoupon is disabled.

[Soft79]

Place it before line 449 of that file and check the debug trace.

[Jonathan Moore]

sure, added one..
I’ve just rewritten the coupon translation to use WC_Coupon everywhere (and so woocommerce’s caching) and avoid loading any posts or use any posts api, I’ll just make sure that’s fine and leave WJECF_AutoCoupon turned off till I have time to debug it further.

[Author]

Posts