Exhausted memory

[Mike Rockett]

Hi guys,

I've stumbled into a little problem I'm not sure how to diagnose.

Recently, I switched Jumplinks development from a 2.8 env to a 3.0 env, and I missed out on some namespace changes (specifically to wire() and __()). Without realising this, I uninstalled the module to test some changes to the installer, but it threw errors for lines that contained non-namespaced calls. I fixed these and then refreshed (via F5), and now I get this:

Quote

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) in ...\wire\core\WireFileTools.php on line 670

Not sure what's causing this, or how to check. I have checked that the module is uninstalled, and it does appear to be. Related tables were removed; page was deleted.

Any ideas what I can do to solve this?

Plus, I picked up on this several times when working on this PR, specifically when there was a small problem with the code that could throw an exception.

[LostKobrakai]

I'd expect some kind of memory leak in the compiler code, which is (at least partly) managed by the WireFileTools class. Maybe it's trying to hard to exclude your no-longer existing path you want to exclude.

[Mike Rockett]

7 minutes ago, LostKobrakai said:

Maybe it's trying to hard to exclude your no-longer existing path you want to exclude.

Right, so I've gone ahead and checked the path that is being worked with by WireFileTools (by means of var_dump($file) at L670), and it keeps repeating this, over and over:

".../site/modules/MarkupSitemapXML/MarkupSitemapXML.module"

It does this until it runs out of memory.

[BitPoet]

Does moving your module code out of the PW path fix anything?

[Mike Rockett]

6 minutes ago, BitPoet said:

Does moving your module code out of the PW path fix anything?

Well, I disabled MarkupSitemapXML manually (as that was the module WireFileTools was working with) and then it did the same thing for ProcessWireUpgrade. As such, I doubt that will solve the problem (WireFileTools hasn't touched Jumplinks).

Edit: Confirmed - behaviour/error persists.

Edited October 2, 2016 by Mike Rockett

[BitPoet]

I admit that I don't have too much clue about all the steps and timings in FileCompiler, but it does look like something got bent around to cause the endless recursion. Perhaps deleting the jumplinks directory in site/assets/cache/FileCompiler and deleting the database entry in the caches table cures the problem? If yes, it's likely some kind of naming clash, though that may already be fixed by your latest changes.

[Mike Rockett]

1 minute ago, BitPoet said:

I admit that I don't have too much clue about all the steps and timings in FileCompiler, but it does look like something got bent around to cause the endless recursion. Perhaps deleting the jumplinks directory in site/assets/cache/FileCompiler and deleting the database entry in the caches table cures the problem? If yes, it's likely some kind of naming clash, though that may already be fixed by your latest changes.

I have already tried that, it just continues doing the same thing with the upgrade module.

For the purposes of not bending my brain too far today, I'm going to move the module to a separate, fresh install and develop on that. As I'm sure someone may have an answer for this, I'll keep the current environment in tact and just won't use it.

[Mike Rockett]

I think that my PR is actually the problem. Disabling that block of code seems to reduce the amount of memory used and allows everything to continue as normal. I had assumed that the method in question (compile) doesn't get called for every single file, but rather for every module. Is this correct? If not, is there a better way to do what I'm trying with that PR?

Also, it seems really odd, because this was working before. No clue why it's all of a sudden giving problems after a few namespace changes (adding \ProcessWire\ to wire() calls).

[Mike Rockett]

Or perhaps not, If I dump $moduleName from that method, ProcessJumplinks repeats.

So I must have a problem with the module - otherwise it wouldn't be doing this.

[ceberlin]

Have you got Tracy Debugger running? I have a memory warning coming from core/Wire.php right now while looking for changed files, which goes away if I deactivate the module (not sure it is related to your problem, just wanted to mention it.)

[adrian]

8 minutes ago, ceberlin said:

Have you got Tracy Debugger running? I have a memory warning coming from core/Wire.php right now while looking for changed files, which goes away if I deactivate the module (not sure it is related to your problem, just wanted to mention it.)

I'd obviously like to know more about this - could you help to narrow it down to a specific panel - use the panel selector to disable all panels and add them back in one at a time.

Or perhaps even just look at the ms/kb values on that panel to see which the culprit might be.

[ceberlin]

@adrian I am just about to checking this for you to report it later. (I am not sure it is the module, it might be MAMP4 on localhost, for example, so I was checking here for possible similarities).

[Mike Rockett]

6 hours ago, ceberlin said:

Have you got Tracy Debugger running? I have a memory warning coming from core/Wire.php right now while looking for changed files, which goes away if I deactivate the module (not sure it is related to your problem, just wanted to mention it.)

The original setup (still in tact) has Tracy installed, but the new one doesn't. I have it working now on the new setup with my PR code active, but I fear it may not actually work at install-time - I need to test that again. I have also asked Ryan in the PR itself if he caan have a look at this - perhaps he may see something I have missed.