skip to content

In Xdebug 3's default develop mode, what changes about var_dump() output and PHP error messages?

level: juniorimportance: should knowfreq 28%

answer

  1. active without any configuration
  2. var_dump() shows file and line
  3. depth 3, 128 children, 512 characters
  4. stack trace appended to errors
  5. recursion guard at 512 frames

basics

~10 s

Develop mode overloads var_dump() to print the calling file and line with depth and size limits, adds a stack trace to error messages, and aborts runaway recursion at xdebug.max_nesting_level (512) with an Error.

solid answer

~30 s

`develop` is Xdebug 3's default mode. It replaces `var_dump()` with Xdebug's version: output starts with the file and line of the call, is formatted and coloured in HTML (and on the CLI with `xdebug.cli_color`), and is cut off at `xdebug.var_display_max_depth` (3), `xdebug.var_display_max_children` (128) and `xdebug.var_display_max_data` (512 characters). It overrides PHP's error display so that notices, warnings and fatal errors show a **call stack**; `xdebug.show_local_vars`, `xdebug.show_exception_trace` and `xdebug.show_error_trace` add more. It also guards against runaway recursion: past `xdebug.max_nesting_level` frames (512 since 3.3, 256 before) it throws an `Error`. `xdebug_var_dump()` itself is available in any mode.

code

php · 16 lines
php
<?php
declare(strict_types=1);

// with xdebug.mode=develop (the default)
$config = ['db' => ['primary' => ['options' => ['timeout' => 5]]]];
var_dump($config);
// prints the file and line first, e.g. /app/dump.php:6:
// and shows 'options' => array (size=1) followed by ... (max depth 3)

function depth(int $n): int
{
    return depth($n + 1); // runaway recursion
}
depth(0);
// Error: Xdebug has detected a possible infinite loop, and aborted
// your script with a stack depth of '512' frames

go deeper

for a junior

Recall that develop mode is on by default, that var_dump() then shows the file and line and truncates at depth 3, and that errors gain a stack trace.

for a middle

Explain the var_display_max_* limits, the show_*_trace settings and why a correct deep recursion can fail with Xdebug loaded.

for a senior

Recognise develop-mode side effects in a bug report — truncated dumps, recursion errors, verbose error pages — and keep them out of any shared or production environment.

for a principal

Set team defaults for development images: which helpers stay on, what the recursion limit is, and how develop mode is kept off every image that reaches users.

## Develop mode is the default **Develop mode** (`xdebug.mode=develop`) is a group of development helpers, and it is the value `xdebug.mode` takes when you install Xdebug and configure nothing. Many developers meet it without knowing it: a local PHP build suddenly prints `var_dump()` output with a file name on top, or errors grow a table of function calls. Those are develop-mode features. ## The overloaded var_dump() With develop mode active, PHP's `var_dump()` is routed through `xdebug_var_dump()`. Compared with the built-in function it: - prints the **file and line** where `var_dump()` was called, e.g. `/app/src/Report.php:42:` — invaluable when stray dumps are scattered through a codebase; - uses a more compact layout, with each key and its type on one line; - adds `<pre>` tags and a colour per type in HTML contexts (when PHP's `html_errors` is on); on the command line colours need `xdebug.cli_color=1`; - marks recursion and shows which object it points back to. It also **truncates** large structures, which surprises people who expect the full dump: | Setting | Default | Limits | |---|---|---| | `xdebug.var_display_max_depth` | `3` | Nesting levels shown | | `xdebug.var_display_max_children` | `128` | Array elements or object properties shown | | `xdebug.var_display_max_data` | `512` | String length before an ellipsis | Set the children or data limit to `-1` to remove it; for depth, `-1` selects the maximum of 1023 levels. The same limits apply to values printed in stack traces and function traces. The function `xdebug_var_dump()` can be called in any mode; only the overloading of `var_dump()` needs develop mode. ## Stack traces on errors When Xdebug is loaded in develop mode, it replaces PHP's error-display callback with one that appends a **call stack**: every function between the start of the script and the point of the error, with time, memory, and file and line. Related settings: 1. `xdebug.show_local_vars` (default `0`) — also print the variables in the local scope of the top frame. 2. `xdebug.show_exception_trace` (default `0`) — print a stack trace whenever an exception or `Error` is thrown, **even if it is caught**. 3. `xdebug.show_error_trace` (default `0`) — the same, but only for `Error` throwables. 4. `xdebug.force_display_errors` and `xdebug.force_error_reporting` — override PHP's `display_errors` and `error_reporting`. 5. `xdebug.scream` — disable the `@` suppression operator so hidden warnings appear. The traces are shown only where PHP would display the error at all, so `display_errors` still matters; and a user error handler registered with `set_error_handler()` can take over the error before Xdebug formats it. ## The infinite-recursion guard Develop mode counts stack frames. When the depth reaches `xdebug.max_nesting_level`, Xdebug throws an `Error` with the message *"Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '512' frames"*. The default rose from **256 to 512 in Xdebug 3.3**. Deeply recursive but correct code — recursive-descent parsers, tree walkers — can hit it only when Xdebug is loaded, so the fix is to raise the setting or set it to `-1`, not to refactor production code for a development-only limit. ## Other helpers in the same mode - `xdebug_call_class()`, `xdebug_call_function()`, `xdebug_call_file()`, `xdebug_call_line()` — who called the current function. - `xdebug_get_function_stack()` and `xdebug_print_function_stack()` — the current stack as an array or printed. - `xdebug_start_function_monitor()` — record where given functions are called from. - `xdebug_memory_usage()`, `xdebug_peak_memory_usage()`, `xdebug_time_index()`. ## Turning the helpers off Xdebug 2 had `xdebug.overload_var_dump`, `xdebug.default_enable` and the functions `xdebug_disable()` and `xdebug_enable()`; Xdebug 3 removed all of them. The only switch now is the mode: list the modes you want **without** `develop` — for example `xdebug.mode=debug` for step debugging alone — and PHP's own `var_dump()` and error output return. PHP's `html_errors` setting also affects the HTML formatting, because the overloaded `var_dump()` and the stack traces render as HTML only when it is on. On the command line the same helpers are active: `var_dump()` still prints the location and applies the display limits, in plain text unless `xdebug.cli_color` asks for colours. A CLI script that dumps a large structure to a file can therefore produce truncated output on a developer machine and complete output on a server without Xdebug — a classic "works differently on my machine" report. ## Why it matters Develop mode costs something on every call — Xdebug keeps its own stack of frames for the traces and the recursion guard — which is one reason not to leave the extension installed on production servers. And its error output, with arguments and optional local variables, is exactly the detail you never want shown to a visitor.

  • A var_dump() of a nested configuration array shows '...' below the third level. Is data missing?
    No. With develop mode active, `var_dump()` is Xdebug's overloaded version, which stops at `xdebug.var_display_max_depth` (default 3) and also caps children at 128 and strings at 512 characters. Raise the settings (`-1` lifts the children and data caps and sets depth to its maximum of 1023) to see more; the array itself is intact.
  • A correct recursive parser throws 'possible infinite loop' only on developer machines. Why?
    The message comes from Xdebug's develop-mode recursion guard, which throws an `Error` once the stack reaches `xdebug.max_nesting_level` frames (512 since Xdebug 3.3). Production has no Xdebug, so no guard. Raise the setting or set it to `-1` in the development ini file.

saying these in an interview costs you the question

  • Xdebug's var_dump() shows the whole structure however deep it is
  • Develop mode must be switched on explicitly after installing Xdebug
  • The 'possible infinite loop' error comes from PHP itself
  • xdebug_var_dump() only exists when develop mode is enabled