1

I've inherited a highly problematic site built in Drupal 7. Upon installing the site on my dev space I get a 'This page isn’t working' error 500. Looking at the web logs I get this message:

lmu.[sitename].co.uk [Sat Apr 23 15:39:03 2022] [error] [client 86.174.32.32:0] AH01215: PHP Fatal error: Out of memory (allocated 56098816) (tried to allocate 459743 bytes) in /home/sites/[sitename].co.uk/public_html/lmu/includes/database/database.inc on line 2324: /home/sites/[sitename].co.uk/public_html/lmu/index.php

The memory_limit was 128M and is now 512M but I get exactly the same error with the same numbers etc.

Is this to do with something contained within the DB?

Additional Edits:

Another, maybe related, issue is that on another server the site runs but only with PHP 5.6 (both updated and non-updated versions of the site). On the server that this question pertains to it is also running 5.6. However, when I attempt to use 7.4 the site still fails but I get a different error message relating to the Database that might provide further clues:

Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 15563655396262a9bd4cef06.08066829 ) in lock_release_all() (line 269 of /home/sites/[sitename].co.uk/public_html/lmu/includes/lock.inc).

Improve this question
8
  • 2
    It’s basically impossible to say without profiling the page request - if the allocated byte amount was large, you could probably be confident enough to point to that script being the culprit, but it’s not, it’s 0.5mb. So either that db call was isolated, and just the unlucky loser that tried to get some memory when all the rest was gone, or that db call is being invoked recursively/exhaustively by something else which is stopping the memory from being reclaimed. Either way you need to wind back through the stack trace and see what’s going on
    – Clive ♦
    Commented Apr 23, 2022 at 18:27
  • 1
    Agreed. The last code to allocate memory isn’t necessary the culprit. But it could be.
    – mona lisa
    Commented Apr 23, 2022 at 18:35
  • Cheers @Clive. I'm not sure of the best procedure to investigate the stack in this context (I'm coming from a frontend background, pls forgive me!). Could you please give me some pointers if possible?
    – james6848
    Commented Apr 23, 2022 at 19:08
  • 2
    Oh I missed the "same numbers" bit before, that's actually pretty crucial, my bad - are you positive about that? If so, 56098816 is exactly 56mb, which suggests your PHP limit isn't what you think it is...maybe you're editing the wrong php.ini file or haven't restarted php-fpm/apache after altering it?
    – Clive ♦
    Commented Apr 23, 2022 at 19:39
  • 5
    Also make sure you're checking the limit in the right context - it's not unusual, in some environments, for there to be different PHP config for CLI vs web, so if you're getting 128mb on the command line, it doesn't necessarily mean the web server is getting the same amount. Simplest way to check is to add a test.php in the web root containing <?php echo ini_get('memory_limit'); and visit test.php in the browser.
    – Clive ♦
    Commented Apr 23, 2022 at 19:51

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.