X-Cart forums

[JannieB]

Trying to redeploy the store and it is hanging on step 8.

The error in the php erros log is:

[18-Mar-2015 15:03:44] Error (code: 1): Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1024983041 bytes)
Server API: cgi-fcgi;
Request method: GET;
URI: /admin.php?1426691019.7061&cpid=3efe898fd35c3a7cd8273b5beecdbe6f;
Backtrace: 
#0  Includes\ErrorHandler::logInfo(Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1024983041 bytes), 1) called at [/var/www/vhosts/moletamunro.com/httpdocs/Includes/ErrorHandler.php:327]
#1  Includes\ErrorHandler::handleError(Array ([type] => 1,[message] => Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1024983041 bytes),[file] => /var/www/vhosts/moletamunro.com/httpdocs/Includes/ErrorHandler.php,[line] => 85)) called at [/var/www/vhosts/moletamunro.com/httpdocs/Includes/ErrorHandler.php:312]
#2  Includes\ErrorHandler::shutdown()

I have tried deleting the .rebuildstarted and trying it again several times but to no avail. I have rest the memory limit to 1G (which is huge!!) and still getting the same error.

Prior to this error is another error:

[18-Mar-2015 15:01:46] Error (code: 2): file_get_contents(/var/www/vhosts/moletamunro.com/httpdocs/var/run/classes/XLite/Module/zzJB/zzMM/View/Shipping.php): failed to open stream: No such file or directory in file /var/www/vhosts/moletamunro.com/httpdocs/Includes/Decorator/Utils/Tokenizer.php : 359
Server API: cgi-fcgi;
... then the whole backtrace 

The zzJB/zzMM is my custom module. I don't have (and never did have) a file called "shipping.php" in this module.

I am tearing my hair out with this .... I was just doing final tweaks before the site goes live ....

any help/advice greatly appreciated

Jan

x-cart 5.1.11 by the way

[JannieB]

Have resolved the missing files issue but it's still hanging on a memory error .... anybody any idea what could be causing this ...

[totaltec]

Jan,
I have ran into these memory errors before on a client site. Some I have fixed after finding an error in my code. Some I have not fixed and just found a workaround which I will describe below.

As you know, this error represents a memory leak in PHP. Looking at your error above, your memory limit is set sky high and setting it higher will probably not help. The site is getting stuck in an infinite loop.

Somewhere there is a code error, or a logic fallacy that repeats a loop until true and never resolves to true. At least that is my hypothesis.

Here is what I would try, disable your custom module by directly editing the database and setting the enabled value ( table "xc_modules" column "enabled" ) to 0. Then rebuild the cache/redeploy the store. Does it come up? If so then you know it is your module.

[JannieB]

Thanks totaltec - I tried disabling my module and doing the rebuild, but it still hangs ...
I am completely mystified now ....

Jan

[totaltec]

Maybe manually deleting things like the datacache folder? Who knows? Completely uninstall your module. Mark it as uninstalled in the DB and completely remove it from the classes and all skin directories.

I am sure you have it packed up where you can reinstall it, but if not you can just manually copy the files while keeping the structure the same so you can paste them back in if needs be.

I am targeting your module because I am assuming that is where the issue lies. By taking it completely out of the equation, we can determine where the true problem lies. You can easily spin up fresh instance of X-Cart and install your module there. If that works than we can rule out your module.

After removing your module file, I would literally do a file diff in Winmerge or similar, without including var or images or files, against your fresh instance of XC just to see if there are changes. If all is well then we can rule out XC's files and your module. And then we can start looking at the database for corruption.

If all is well in a fresh install of XC, can we just port the language tables and the products from the dev site to the fresh install? With an import/export?

If all is not well with XC itself (and it's modules), can we disable the modules one by one to see if any are causing the problem?


I have to say, memory leaks like this are pretty frustrating. The error message is not helpful at all. If only PHP had some kind of garbage collector, or some way to show exactly where the leak is coming from! I am sure someone with more knowledge than I could help pinpoint the problem, there has to be a way to find out the origin. All the methods I can suggest are very tedious and labor intensive. But from what I can tell about you, you will persevere till it is found.

Maybe someone else can share some techniques for tracking this nasty bugger down. Tony? Alex?


Here is my experience: I have a client site that was built on what I would consider a beta version of XC, with many modules (custom and official) installed and uninstalled over the last couple years. It has a highly customized skin built by QSL (autoparts). At this point, its honestly a mangled limping dog of a site. Every time we rebuild cache it hangs on step 8. Same type of memory leak.

We have found that it will rebuild perfectly without the QSL skin enabled. And it will rebuild after the QSL skin is enabled. But it will only rebuild once. On the next rebuild, you will have to disable the QSL skin or it will hang. So if you make any changes to modules on this site and need to rebuild, you first have to disable the QSL skin, which triggers a rebuild; make your changes, then re-enable the QSL skin, rebuild. This may be your workaround that I mentioned earlier. But you need to narrow it down to which module is the culprit. That took us 2 days of work, on a job we only billed 2 hours for. Ouch.

[JannieB]

thanks for your suggestions .... it seems like that's my next step... or steps ...

A couple of other facts to throw into the mix ....

1) The last successful rebuild was on 13th March, so not long ago. I have gone through and removed or reverted everything changed since then (not much).

2) The server the site is on is running 5.3.3. The day before I tried to rebuild, I asked the server guys to install the latest version of PHP on th server, so that I could choose which version to use for each site. This site is still on the same version of PHP. I got the server guys to check that the fgci settings were still the same as before (and as x-cart recommends), which they are. But it seems a coincidence that this should happen straight afterwards. I am wondering if there is a config setting or something somewhere which needs to change? Or some sort of cache which needs to be cleared?
I will go back to the tech guys to see if there's anything in the server logs ....

All very tedious! Thanks for your help - I will let you know what I discover...

Jan

[totaltec]

Good luck. I don't think it's the PHP version. When I have dealt with a memory leak like this, I transferred the site to myltiple environments to test and it happened every time in every setup.

[JannieB]

Update:

Managed to get the site back .... not quite sure what was going on ..

While trying one of the endless redeploys I noticed in the decorator log that it had actually gone right the way through to step 11 and then started again. On the second run through it would hang at step 8.

curiouser and curiouser ....

I was triggering the rebuild by deleting the cachegenerated files in var/run/ and then deleting the .rebuildstarted file in var. Then I was going to the admin page and hitting refresh.

So I tried disabling my modules, deleting the files as above, then went to a new browser to open the admin page. Amazingly this worked!

I then re-enabled each module individually, rebuilding in-between and it still redeployed OK.

There is some functionality missing, but that will be down to my module code, so I can actually debug that!

Now I can get back to doing the things I was going to do a couple of days ago....

Jan