Fatal error - allowed memory size exhausted

[vsn]

TB 1.0.8, PHP 7.1.29, If trying to open different tabs in BO (like settings -> general setting) got the following error:

<b>Fatal error</b>:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 400560128 bytes) in <b>/var/www/vhosts/happypostcards.aix-cloud.de/httpdocs/ThirtyBees/Happypostcards/classes/exception/PrestaShopException.php</b> on line <b>240</b><br />

Server settings:

PHP-Version 7.1.29

Memory limit 512M

max_execution_time 600

 

[tommat]

You need to raise memory limit on your server

[vsn]

It was sufficient in case of TB 1.0.7 & PHP5. I just update my TB yesterday and changed PHP to 7.1. Additionally this is a shared server. Any ideas?

[datakick]

The memory limit is a red herring, not a root cause. There is some error thrown somewhere, and error reporting engine tries to serialize this error message and output it to error page (encrypted). If the context is large enough, this operation can easily lead to memory exhaustion. 

This problem is fixed (or mitigated) in bleeding edge. So, if you can, try to use core updater and update your shop to bleeding edge. That should fix the error reporting issue.

Then the root cause will be revealed -- and of course, you will have to fix that one as well. 

[vsn]

Yes, this seems to be the case. Yesterday I manually applied the following fix https://github.com/thirtybees/thirtybees/commit/bdb04ce186c13bc60b3f2fbd6805d88cf349a738?diff=unified#diff-d373723286a172a4ca3d76c4858f565b

I just manually changed 4 files mention in the fix, replaceing the old code with a new one described in a bug fix. Now I rolled back - it works. But how to fix the ccs saving issues?

[datakick]

Sometimes cherry picking single commit doesn't work -- for example, it might depend on some code that was committed before this commit, but is not part of 1.0.8

The only answer I can give you is to use core updater and update whole shop to bleeding edge.  

 

[vsn]

Using bleeding edge... what kind of quality management process is used? Can anybody ensure all the fixes are compatible with each over and everything works? And not will be broken with the next update? I personally like version model - you tested it, you know how does it work. Am I wrong?

By the way, I fixed the issue by putting ccs into TB native custom code tab.

[Traumflug]

Well, I think it's time to talk a bit about this next release. Last November, I planned to release it on New Year's Eve. As everybody can see, this didn't work out.

How could such an utter mis-planning happen? Well, there was this issue with broken price rounding. A Github issue and the reporter even sent me a patch for correcting the misbehavior. Should be a matter of a day for applying and testing this patch, right? Things turned out to be not that simple. Each look at the code came up with more small issues regarding price rounding, the TODO list grew and grew ... and it took over two month to settle the whole topic. Then thirty bees had much more reliable price rounding, but it was also late February.

A similar thing happened a couple of weeks ago. thirty bees 1.1.0 will come with a much nicer, cleaner theme. Switching the default theme on installation should be a matter of flipping a switch, right? Well, as it turned out, not really. Initial theme installation was found to be entirely distinct from a theme installation done in back office. Huge amounts of handcrafted SQL and XML files instead of a procedure installing the actual theme. Which means, since 4 weeks I'm working on separating theme installation from AdminThemesController, into class Theme, to make it available to the installer as well, and to get rid of all the handcrafted SQL and XML, which is hard to adjust to another theme. Also fixing bugs found in this area, of course. I'm not there yet, probably it'll take another two or three weeks. And then I can flip the switch.

What does this mean for merchants? Good thing is, they're not lost. During all the time described above, branch 1.0.x wasn't abandoned, but received many many bug fixes, making thirty bees more stable than ever before. The only thing missing thing there is a formal release. Making such a release would throw back the 1.1.0 release by another week or so, so it's not on the TODO list. We have Core Updater, after all, and @datakick regularly runs some voodoo to update its master repository, which allows to update to latest 1.0.x. That's what a merchant should do. It's named "Bleeding edge", actually it's currently more stable than "Stable".

Want a return to monthly releases? Yes, me too!

[SLiCK_303]

That post should have been its own topic, as I'm sure many people will have questions about it, as do I......

Does 1.0.x "bleeding-edge" have the price rounding fixes in it?

Will 1.1.x come with 2 themes or just Niara in it?

Once 1.1.x comes out, will you still work on the 1.0.x path?

Is 1.1.x backward compatible with 1.0.x, as far as modules and themes go?

Thanx for the update on whats going on, and all you guys working on the project!!!

[Traumflug]

12 hours ago, SLiCK_303 said:

Does 1.0.x "bleeding-edge" have the price rounding fixes in it?

Yes.

12 hours ago, SLiCK_303 said:

Will 1.1.x come with 2 themes or just Niara in it?

It'll come with both themes.

12 hours ago, SLiCK_303 said:

Once 1.1.x comes out, will you still work on the 1.0.x path?

There's no point in doing so.

12 hours ago, SLiCK_303 said:

Is 1.1.x backward compatible with 1.0.x, as far as modules and themes go?

Yes, except for PHP 5.5 compatibility. PHP 5.6 will be the oldest PHP version supported, then.