I definitely do not know how to solve this. What I can say is that the line number referenced is a loop in the garbage_collect routine of qa.php, which is building an array of items it will issue an SQL DELETE operation on to dispose of the now-unneeded data. So to hit the memory limit on that line implies that either this garbage collection is encountering an unusually huge number of items that need to be disposed of, or, there is some kind of corrupt or malicious single item that is singularly huge.
Then it looks like it's definitely related to be the garbage collector. I'm also looking into an issue with the server (a tmp folder getting lots of 11Mb files each day (totalling more than 8-12 Gb/d)) and my reasearch found that I'm not the only one having this problem with the latest Vesta CP, so after your message and looking at the times those 11 Mb files appeared. I stopped most cron jobs there and the identification is apparently working now as it should, but I still need to check if both things are related or it is working now by chance.EA117 wrote: ↑Mon Feb 25, 2019 10:27 pmI definitely do not know how to solve this. What I can say is that the line number referenced is a loop in the garbage_collect routine of qa.php, which is building an array of items it will issue an SQL DELETE operation on to dispose of the now-unneeded data. So to hit the memory limit on that line implies that either this garbage collection is encountering an unusually huge number of items that need to be disposed of, or, there is some kind of corrupt or malicious single item that is singularly huge.
The array qa.php is building at that line is a list of "confirm_id" values (32-character string each). So when seeing the description of "tried to allocate 33554440 bytes" (32MB), it just makes me think "that would be room for a whole lot of 32-character strings." (At least half a million of them.) Which is what made it seem like there could be some kind of data issue instead -- making the array or at least one of the array items larger than it should be -- leading to a memory allocation attempt that exceeds what was intended or expected.
Thanks for the correction... an important distinction that I was ignoring, and a point that Mick had also made but flew right over my head. ("Allowed PHP memory" versus "available server memory.")
Allowed memory size
. Increase that in php.ini, or ask you host.Code: Select all
/phpbb/db/driver/driver.php on line 573