PHP's fatal errors are notoriously unhelpful at first glance — a wall of text, a file and line number that's often just where the failure was detected rather than where the actual mistake lives, and a message that assumes you already know what went wrong. Here's what the most common ones actually mean, and how to track down the real cause instead of guessing.
"Call to undefined function" / "Call to undefined method"
PHP is telling you it looked for a function or method by that exact name and found nothing. The usual suspects, roughly in order of likelihood:
- A typo in the function/method name (check case — PHP function names are case-insensitive, but method names on objects can still trip you up with autoloading).
- A required PHP extension isn't installed on this server (common after moving from local dev to shared hosting —
gd,mbstring, andcurlare frequent gaps). - The class defining the method was never loaded — often an autoloader/namespace mismatch rather than a missing file.
"Class not found"
Almost always an autoloading problem, not a missing file. Check that the namespace declared at the top of the class file matches its location on disk (PSR-4 expects them to line up), and that composer dump-autoload has actually been run after adding a new class.
"Maximum execution time exceeded"
The script ran longer than max_execution_time allows (30 seconds by default on most hosts). This is rarely actually about the timeout setting — it's a symptom of something taking too long: an unindexed database query, a loop that's doing far more work than it should, or an external API call with no timeout of its own that's hanging. Raising the limit treats the symptom; finding the slow operation fixes the cause.
"Allowed memory size exhausted"
PHP hit its memory_limit. Before bumping the limit in php.ini, look for the obvious culprits: loading an entire large file into memory with file_get_contents() instead of streaming it, building a huge array in a loop that should be processed incrementally, or a recursive function with no proper base case quietly ballooning memory on every call.
"Cannot redeclare function/class"
A file got required or included more than once. Nine times out of ten the fix is simply switching to require_once / include_once at whichever call site is duplicating the load — this is an easy one to introduce when two different files each pull in the same dependency without checking whether it's already loaded.
Reading the stack trace correctly
A PHP stack trace lists calls in reverse order — the most recent call (closest to where things broke) is at the top, and the trace runs backward to the original entry point at the bottom. The line number in the main error message tells you where PHP noticed the problem, which is frequently a few calls downstream of the actual mistake. Read the trace from the top down until you reach a line number and file that's actually part of your own codebase, not a vendor library — that's usually your real starting point.
When the stack trace still isn't enough
On a busy production app, a raw stack trace can run to hundreds of lines across a dozen files, and manually tracing it back to root cause eats real time. Our Full PHP Error Stack Analyzer parses the full trace and pinpoints the exact file and line where things actually went wrong (with support for Laravel, Symfony, and WordPress stack formats specifically), and the Fatal Error Root Cause Finder goes a step further, classifying whether you're looking at a memory issue, a timeout, or a version-incompatibility problem so you're fixing the right thing on the first try.