This setting, defaulting to 0, controls whether Xdebug should add variable assignments to function traces. Assign-by-var (=&) assignments are included too.

If enabled (default), files created with the Function Trace feature will include all arguments to functions and methods.

When disabled, the argument to each function and method will not be present in the trace files.

This setting, defaulting to 0, controls whether Xdebug should write the return value of function calls to the trace files.

Configures Xdebug's log file.

Xdebug will log to this file all file creations issues, Step Debugging connection attempts, failures, and debug communication.

Enable this functionality by setting the value to a absolute path. Make sure that the system user that PHP runs at (such as www-data if you are running with Apache) can create and write to the file.

The file is opened in append-mode, and will therefore not be overwritten by default. There is no concurrency protection available.

The log file will include any attempt that Xdebug makes to connect to an IDE:

[2693358] Log opened at 2020-09-02 07:19:09.616195
[2693358] [Step Debug] INFO: Connecting to configured address/port: localhost:9003.
[2693358] [Step Debug] ERR: Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port).
[2693358] [Profiler] ERR: File '/foo/cachegrind.out.2693358' could not be opened.
[2693358] [Profiler] WARN: /foo: No such file or directory
[2693358] [Tracing] ERR: File '/foo/trace.1485761369' could not be opened.
[2693358] [Tracing] WARN: /foo: No such file or directory
[2693358] Log closed at 2020-09-02 07:19:09.617510

It includes the opening time (2020-09-02 07:19:09.616195), the IP/Hostname and port Xdebug is trying to connect to (localhost:9003), and whether it succeeded (Connected to client). The number in brackets ([2693358]) is the Process ID.

It includes:

[2693358]

process ID in brackets

2020-09-02 07:19:09.616195

opening time

For Step Debugging:

INFO: Connecting to configured address/port: localhost:9003.
ERR: Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port).

For Profiling:

ERR: File '/foo/cachegrind.out.2693358' could not be opened.
WARN: /foo: No such file or directory

For Function Trace and Flame Graphs:

ERR: File '/foo/trace.1485761369' could not be opened.
WARN: /foo: No such file or directory

All warnings and errors are described on the Description of errors page, with detailed instructions on how to resolve the problem, if possible. All errors are always logged through PHP's internal logging mechanism (configured with error_log in php.ini). All warnings and errors also show up in the diagnostics log that you can view by calling xdebug_info().

Step Debugger Communication

The debugging log can also log the communication between Xdebug and an IDE. This communication is in XML, and starts with the <init XML element:

<init
    xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
    fileuri="file:///home/httpd/www.xdebug.org/html/router.php"
    language="PHP" xdebug:language_version="7.4.11-dev"
    protocol_version="1.0" appid="2693358" idekey="XDEBUG_ECLIPSE">
        <engine version="3.0.0-dev"><![CDATA[Xdebug]]></engine>
        <author><![CDATA[Derick Rethans]]></author>
        <url><![CDATA[https://xdebug.org]]></url>
        <copyright><![CDATA[Copyright (c) 2002-2020 by Derick Rethans]]></copyright>
</init>

The fileuri attribute lists the entry point of your application, which can be useful to compare to breakpoint_set commands to see if path mappings are set-up correctly.

Beyond the <init element, you will find the configuration of features:

<- feature_set -i 4 -n extended_properties -v 1
-> <response
       xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
       command="feature_set" transaction_id="4" feature="extended_properties" success="1">
   </response>

And continuation commands:

<- step_into -i 9
-> <response
       xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"
       command="step_into" transaction_id="9"
       status="break" reason="ok">
           <xdebug:message filename="file:///home/httpd/www.xdebug.org/html/router.php" lineno="3">
           </xdebug:message>
   </response>

You can read about DBGP - A common debugger protocol specification at its dedicated documation page.

The xdebug.log_level setting controls how much information is logged.

Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to: /tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg

This setting can additionally be configured through the XDEBUG_CONFIG environment variable.

Configures which logging messages should be added to the log file.

The log file is configured with the xdebug.log setting.

The following levels are supported:

Criticals, errors, and warnings always show up in the diagnostics log that you can view by calling xdebug_info().

Criticals and errors are additionally logged through PHP's internal logging mechanism (configured with error_log in php.ini).

This setting can additionally be configured through the XDEBUG_CONFIG environment variable.

This setting controls which Xdebug features are enabled.

This setting can only be set in php.ini or files like 99-xdebug.ini that are read when a PHP process starts (directly, or through php-fpm). You can not set this value in .htaccess and .user.ini files, which are read per-request, nor through php_admin_value as used in Apache VHOSTs and PHP-FPM pools.

The following values are accepted:

off

Nothing is enabled. Xdebug does no work besides checking whether functionality is enabled. Use this setting if you want close to 0 overhead.

develop

Enables Development Helpers including the overloaded var_dump().

coverage

Enables Code Coverage Analysis to generate code coverage reports, mainly in combination with PHPUnit.

debug

Enables Step Debugging. This can be used to step through your code while it is running, and analyse values of variables.

gcstats

Enables Garbage Collection Statistics to collect statistics about PHP's Garbage Collection Mechanism.

profile

Enables Profiling, with which you can analyse performance bottlenecks with tools like KCacheGrind.

trace

Enables the Function Trace and Flame Graphs features.

The former allows you record every function call, including arguments, variable assignment, and return value that is made during a request to a file.

The latter can be used to visualise certain performance characteristics.

You can enable multiple modes at the same time by comma separating their identifiers as value to xdebug.mode: xdebug.mode=develop,trace.

XDEBUG_MODE environment variable

You can also set Xdebug's mode by setting the XDEBUG_MODE environment variable on the command-line; this will take precedence over the xdebug.mode setting, but will not change the value of the xdebug.mode setting.

Some web servers have a configuration option to prevent environment variables from being propagated to PHP and Xdebug.

For example, PHP-FPM has a clear_env configuration setting that is on by default, which you will need to turn off if you want to use XDEBUG_MODE.

Make sure that your web server does not clean the environment, or specifically allows the XDEBUG_MODE environment variable to be passed on.

The directory where Xdebug will write tracing, profiling, and garbage collection statistics to. This directory needs to be writable for the system user with which PHP is running.

This setting can be changed in php.ini, .htaccess (and equivalent files), and within a PHP file with ini_set().

In some cases (when profiling, or when xdebug.start_with_request=yes with tracing), Xdebug creates the file before the script runs. In that case, changes made through ini_set() will not be taken into account.

This setting can additionally be configured through the XDEBUG_CONFIG environment variable.

Many Linux distributions now use systemd, which implements private tmp directories. This means that when PHP is run through a web server or as PHP-FPM, the /tmp directory is prefixed with something akin to: /tmp/systemd-private-ea3cfa882b4e478993e1994033fc5feb-apache.service-FfWZRg

Step Debugging, a Function Trace, Flame Graphs, Garbage Collection Statistics, or Profiling can be activated at the start of a PHP request. Whether this happens depends on the value of this setting:

yes

The functionality starts when the PHP request starts, and before any PHP code is run.

For example xdebug.mode=trace and xdebug.start_with_request=yes starts a Function Trace for the whole request.

no

The functionality does not get activated when the request starts.

You can still start a Function Trace with xdebug_start_trace(), or Garbage Collection Statistics with xdebug_start_gcstats().

Step Debugging and Profiling will never activate with this value.

trigger

The functionality only gets activated when a specific trigger is present when the request starts.

The name of the trigger is XDEBUG_TRIGGER, and Xdebug checks for its presence in either $_ENV (environment variable), $_GET or $_POST variable, or $_COOKIE (HTTP cookie name).

There is a legacy fallback to a functionality specific trigger name: XDEBUG_PROFILE (for Profiling), XDEBUG_TRACE (for a Function Trace or Flame Graphs), and XDEBUG_SESSION (for Step Debugging).

There is another legacy trigger for Step Debugging only. If you set the XDEBUG_CONFIG environment variable to any value, then the step debugger will also get activated.

Debug session management for Step Debugging is also available through XDEBUG_SESSION_START.

With xdebug.trigger_value you can control which specific trigger value will activate the trigger. If xdebug.trigger_value is set to an empty string, any value will be accepted.

In this mode it is also possible to activate Step Debugging with xdebug_break().

default

The default value depends on xdebug.mode:

• debug: trigger

• gcstats: no

• profile: yes

• trace: trigger

The format of the trace file.

Fields for the computerized format, depend on the record type.

Entry Line

Exit Line

Return Line

See the introduction for Function Trace for a few examples.

This settings accepts a bitfield to enable options:

0x01

Trace file data will be appended to an already existing file with the same name, instead of it being overwritten.

0x02

Switches the file format to a tab separated format. The format is described in the xdebug.trace_format setting as "format 1".

0x04

Switches to a file format that shows data as an HTML table

0x08

With this bit set, .xt is not added automatically to the end of trace file names.

0x10

Switches to a file format that provides information for "cost" flamegraphs.

0x20

Switches to a file format that provides information for "memory usage" flamegraphs.

To combine multiple flags, you can use bitwise-OR (|).

xdebug.trace_options=0x02|0x08 enables both the tab separated format, and stops the addition of .xt to the end of the file name.

This setting determines the name of the file that is used to dump traces into. The setting specifies the format with format specifiers, very similar to sprintf() and strftime(). There are several format specifiers that can be used to format the file name. The '.xt' extension is always added automatically.

The possible format specifiers are:

² This one is only available for trace file names since Xdebug 2.6.

³ New in version 2.2. This one is set by Apache's mod_unique_id module

This setting can be used when xdebug.start_with_request is set to trigger, which is the default for Step Debugging and Function Trace.

In trigger mode, Xdebug will only start its functionality when the XDEBUG_TRIGGER is set in the environment, or when the XDEBUG_TRIGGER GET, POST, or COOKIE variable is set.

The legacy names XDEBUG_SESSION (for Step Debugging), XDEBUG_PROFILE (for Profiling), and XDEBUG_TRACE (for Function Trace) can also be used instead of XDEBUG_TRIGGER.

Normally, Xdebug does not look at which value is actually used. If this setting is set to a non-empty string, then Xdebug will only trigger if the value matches the value of this setting.

With the following settings:

xdebug.mode=profile
xdebug.start_with_request=trigger
xdebug.trigger_value=StartProfileForMe

Xdebug's profiler will only start when either the environment variable XDEBUG_TRIGGER is set to StartProfileForMe, the GET or POST variable XDEBUG_TRIGGER is set to StartProfileForMe, or when the cookie XDEBUG_TRIGGER has the value StartProfileForMe.

From Xdebug 3.1, it is possible to configure multiple values by using a comma separated list. In that case, Xdebug will trigger if the supplied value matches any of the entries that are configured through this setting:

xdebug.trigger_value=StartDebuggerForMe,StartDebuggerForYou

See also:

xdebug.start_with_request#trigger

For how the triggering mechanism works, and which environment and server variables Xdebug acts on.

If enabled, the Function Trace and Profiling features will create GZip compressed files as output. This reduces diskspace.

If GZip compression is not supported by Xdebug, because it was not compiled in, then Xdebug will add a warning to its log and xdebug_info() diagnostics section.

It is enabled by default if Xdebug has GZip support, and disable if Xdebug does not have GZip support.

The QCacheGrind tool that you can use to visualise profiling information does not support reading GZip compressed profile files, whereas KCacheGrind and PhpStorm do. If you are a QCacheGrind user, you should set xdebug.use_compression to false.

Controls the amount of array children and object's properties are shown when variables are displayed with either xdebug_var_dump(), xdebug.show_local_vars or when making a Function Trace.

To disable any limitation, use -1 as value.

This setting does not have any influence on the number of children that is send to the client through the Step Debugging feature.

Controls the maximum string length that is shown when variables are displayed with either xdebug_var_dump(), xdebug.show_local_vars or when making a Function Trace.

To disable any limitation, use -1 as value.

This setting does not have any influence on the number of children that is send to the client through the Step Debugging feature.

Controls how many nested levels of array elements and object properties are when variables are displayed with either xdebug_var_dump(), xdebug.show_local_vars or when making a Function Trace.

The maximum value you can select is 1023. You can also use -1 as value to select this maximum number.

This setting does not have any influence on the number of children that is send to the client through the Step Debugging feature.

Setting the value to a high number could potentially result in PHP using up all the available memory, so use with caution.

Returns information about the stack

Returns an array which resembles the stack trace up to this point. The example script:

<?php
    class strings {
        function fix_string($a)
        {
            var_dump(xdebug_get_function_stack());
        }

        function fix_strings($b) {
            foreach ($b as $item) {
                $this->fix_string($item);
            }
        }
    }

    $s = new strings();
    $ret = $s->fix_strings(array('Derick'));
?>

array (size=3)
  0 =>
    array (size=6)
      'time' => float 2.648155248
      'memory' => int 530520
      'function' => string '{main}' (length=6)
      'file' => string 'Standard input code' (length=19)
      'line' => int 0
      'params' =>
        array (size=0)
          empty
  1 =>
    array (size=8)
      'time' => float 2.648221973
      'memory' => int 530664
      'function' => string 'fix_strings' (length=11)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 16
      'params' =>
        array (size=1)
          'b' => string '[0 => 'Derick']' (length=15)
  2 =>
    array (size=8)
      'time' => float 2.648243513
      'memory' => int 530664
      'function' => string 'fix_string' (length=10)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 10
      'params' =>
        array (size=1)
          'a' => string ''Derick'' (length=8)

Through the $options array you can tune what information is returned. These options were introduced in Xdebug 3.3.

$options['local_vars'] #

If you set the local_vars option to true, then the stack trace contains an extra element called variables, which is an array where each element represents a local variable name/value pair:

<?php
    class strings {
        function fix_string($a)
        {
            var_dump(xdebug_get_function_stack( [ 'local_vars' => true ] ));
        }

        function fix_strings($b) {
            foreach ($b as $item) {
                $this->fix_string($item);
            }
        }
    }

    $s = new strings();
    $ret = $s->fix_strings(array('Derick'));
?>

array (size=3)
  0 =>
    array (size=7)
      'time' => float 4.507993828
      'memory' => int 586272
      'function' => string '{main}' (length=6)
      'file' => string 'Standard input code' (length=19)
      'line' => int 0
      'params' =>
        array (size=0)
          empty
      'variables' =>
        array (size=2)
          's' =>
            object(strings)[1]
          'ret' => null
  1 =>
    array (size=9)
      'time' => float 4.508039954
      'memory' => int 586416
      'function' => string 'fix_strings' (length=11)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 16
      'params' =>
        array (size=1)
          'b' => string '[0 => 'Derick']' (length=15)
      'variables' =>
        array (size=2)
          'b' =>
            array (size=1)
              ...
          'item' => string 'Derick' (length=6)
  2 =>
    array (size=9)
      'time' => float 4.508065061
      'memory' => int 586416
      'function' => string 'fix_string' (length=10)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 10
      'params' =>
        array (size=1)
          'a' => string ''Derick'' (length=8)
      'variables' =>
        array (size=1)
          'a' => string 'Derick' (length=6)

The values in the params array are still stringified variants of the values, unlike the one in the variables element.

$options['params_as_values'] #

You can changes these to also be values by setting the params_as_values option.

<?php
    class strings {
        function fix_string($a)
        {
            var_dump(xdebug_get_function_stack( [ 'params_as_values' => true ] ));
        }

        function fix_strings($b) {
            foreach ($b as $item) {
                $this->fix_string($item);
            }
        }
    }

    $s = new strings();
    $ret = $s->fix_strings(array('Derick'));
?>

array (size=3)
  0 =>
    array (size=6)
      'time' => float 5.128140207
      'memory' => int 589968
      'function' => string '{main}' (length=6)
      'file' => string 'Standard input code' (length=19)
      'line' => int 0
      'params' =>
        array (size=0)
          empty
  1 =>
    array (size=8)
      'time' => float 5.128188808
      'memory' => int 590112
      'function' => string 'fix_strings' (length=11)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 16
      'params' =>
        array (size=1)
          'b' =>
            array (size=1)
              ...
  2 =>
    array (size=8)
      'time' => float 5.128214727
      'memory' => int 590112
      'function' => string 'fix_string' (length=10)
      'type' => string 'dynamic' (length=7)
      'class' => string 'strings' (length=7)
      'file' => string 'Standard input code' (length=19)
      'line' => int 10
      'params' =>
        array (size=1)
          'a' => string 'Derick' (length=6)

$options['from_exception'] #

The last option is from_exception, which takes a thrown Exception or Error object as argument. Instead of showing the stack trace of where xdebug_get_function_stack gets called from, you instead get the stack trace of where this Exception or Error was thrown.

This should be used in a user-defined exception handler.

<?php
class Handlers
{
    function __construct(private string $title, private float $PIE) {}

    static function exceptionHandler($exception)
    {
        var_dump( xdebug_get_function_stack( [ 'from_exception' => $exception ] ) );
    }
}

class Elephpant
{
    function __construct(private string $title, private string $PIE) {}
}

class Error_Class
{
    public static function newError($errno = false)
    {
        $elephpant = new Elephpant("Bluey", M_PI);
        $randoVar = 42;

        throw new Exception();
    }

}

class Error_Entry
{
    public function __construct($base, $errno)
    {
        $return = Error_Class::newError(true);
    }
}

set_exception_handler(['Handlers', 'exceptionHandler']);
$e = new Error_Entry(1, 2);

?>

array (size=3)
  0 =>
    array (size=7)
      'time' => float 5.194523655
      'memory' => int 595976
      'function' => string '{main}' (length=6)
      'file' => string 'Standard input code' (length=19)
      'line' => int 0
      'params' =>
        array (size=0)
          empty
      'variables' =>
        array (size=1)
          'e' => null
  1 =>
    array (size=9)
      'time' => float 5.194572727
      'memory' => int 596440
      'function' => string '__construct' (length=11)
      'type' => string 'dynamic' (length=7)
      'class' => string 'Error_Entry' (length=11)
      'file' => string 'Standard input code' (length=19)
      'line' => int 38
      'params' =>
        array (size=2)
          'base' => int 1
          'errno' => int 2
      'variables' =>
        array (size=3)
          'base' => int 1
          'errno' => int 2
          'return' => null
  2 =>
    array (size=9)
      'time' => float 5.194576134
      'memory' => int 596440
      'function' => string 'newError' (length=8)
      'type' => string 'static' (length=6)
      'class' => string 'Error_Class' (length=11)
      'file' => string 'Standard input code' (length=19)
      'line' => int 33
      'params' =>
        array (size=1)
          'errno' => boolean true
      'variables' =>
        array (size=3)
          'errno' => boolean true
          'elephpant' =>
            object(Elephpant)[2]
              ...
          'randoVar' => int 42

The stack trace you get when using params_as_values also always includes the local variables in the variables element, and non-stringified values for the function's arguments in the params element.

Returns information about monitored functions

Returns a structure which contains information about where the monitored functions were executed in your script. The following example shows how to use this, and the returned information:

<?php
/* Start the function monitor for strrev and array_push: */
xdebug_start_function_monitor( [ 'strrev', 'array_push' ] );

/* Run some code: */
echo strrev("yes!"), "\n";

echo strrev("yes!"), "\n";

var_dump(xdebug_get_monitored_functions());
xdebug_stop_function_monitor();
?>

/tmp/monitor-example.php:10:
array(2) {
  [0] =>
  array(3) {
    'function' =>
    string(6) "strrev"
    'filename' =>
    string(24) "/tmp/monitor-example.php"
    'lineno' =>
    int(6)
  }
  [1] =>
  array(3) {
    'function' =>
    string(6) "strrev"
    'filename' =>
    string(24) "/tmp/monitor-example.php"
    'lineno' =>
    int(8)
  }
}

Returns the current stack depth level

Returns the stack depth level. The main body of a script is level 0 and each include and/or function call adds one to the stack depth level.

Returns the name of the function trace file

Returns the name of the file which is used to trace the output of this script to, or false if tracing is not active. This is useful when the trace was started automatically because xdebug.start_with_request was set to yes.

Show and retrieve diagnostic information

This function presents APIs to retrieve information about Xdebug itself. Which information gets returned, or displayed, depends on which arguments, or none at all, are given.

$category =

Without arguments, this function returns an HTML page which shows diagnostic information. It is analogous to PHP's phpinfo() function.

The HTML output includes which mode is active, what the settings are, and diagnostic information in case there are problems with debugging connections, opening of files, etc.

Each warning and error in the diagnostics log also links through to the Description of errors documentation page.

$category = 'mode' (New in Xdebug 3.1)

The function returns an array of all the enabled modes, whether through xdebug.mode or the XDEBUG_MODE environment variable.

<?php
var_dump( xdebug_info( 'mode' ) );
?>

array(3) {
  [0] =>
  string(5) "debug"
  [1] =>
  string(7) "develop"
  [2] =>
  string(5) "trace"
}

$category = 'extension-flags' (New in Xdebug 3.1)

The function returns an array of all the compile flags that were enabled when running ./configure as part of Xdebug's compilation process, and all the system-specific detected features that effect Xdebug's behaviour.

If the compression flag is enabled, then the xdebug.use_compression setting is available, and enabled by default.

Profiling and Function Trace will create GZip compressed files if the xdebug.use_compression setting is turned on (the default).

If the control-socket and tsc elements are present, then Xdebug can be controlled with the Xdebug Control tool, as long as xdebug.control_socket is not set to "off".

If the control-socket flag is present, but the tsc flag is not present, then you must set xdebug.control_socket to "time" deliberately for Xdebug Control to be able to interact with Xdebug.

<?php
var_dump( xdebug_info( 'extension-flags' ) );
?>

array(1) {
  [0] =>
  string(11) "compression"
  [1] =>
  string(14) "control-socket"
  [2] =>
  string(3) "tsc"
}

Displays the current function stack

Displays the current function stack, in a similar way as what Xdebug would display in an error situation.

The "message" argument allows you to replace the message in the header with your own.

<?php
function foo( $far, $out )
{
    xdebug_print_function_stack( 'Your own message' );
}
foo( 42, 3141592654 );
?>

( ! ) Xdebug: Your own message in /home/httpd/html/test/xdebug/print_function_stack.php on line 5
Call Stack
#
Time
Memory
Function
Location
1
0.0006
653896
{main}(  )
../print_function_stack.php:0
2
0.0007
654616
foo( 42, 3141592654 )
../print_function_stack.php:7
3
0.0007
654736
xdebug_print_function_stack
( 'Your own message' )
../print_function_stack.php:5

The bitmask "options" allows you to configure a few extra options. The following options are currently supported:

XDEBUG_STACK_NO_DESC

If this option is set, then the printed stack trace will not have a header. This is useful if you want to print a stack trace from your own error handler, as otherwise the printed location is where xdebug_print_function_stack() was called from.

Starts function monitoring

This function starts the monitoring of functions that were given in a list as argument to this function. Function monitoring allows you to find out where in your code the functions that you provided as argument are called from. This can be used to track where old, or, discouraged functions are used.

<?php
xdebug_start_function_monitor( [ 'strrev', 'array_push' ] );
?>

You can also add class methods and static methods to the array that defines which functions to monitor. For example, to catch static calls to DramModel::canSee and dynamic calls to Whisky->drink, you would start the monitor with:

<?php
xdebug_start_function_monitor( [ 'DramModel::canSee', 'Whisky->drink'] );
?>

The defined functions are case sensitive, and a dynamic call to a static method will not be caught.

Starts a new function trace

Start tracing function calls from this point to the file in the $trace_file parameter. If no filename is given, then the trace file will be placed in the directory as configured by the xdebug.output_dir setting.

In case a file name is given as first parameter, the name is relative to the current working directory. This current working directory might be different than you expect it to be, so please use an absolute path in case you specify a file name. Use the PHP function getcwd() to figure out what the current working directory is.

The name of the trace file is {$trace_file}.xt. If the trace was started at the beginning of the request because xdebug.start_with_request is set to yes, then the filename depends on the xdebug.trace_output_name setting.

The options parameter is a bitfield; currently there are four options:

XDEBUG_TRACE_APPEND (0x01)

Trace file data will be appended to an already existing file with the same name, instead of it being overwritten.

XDEBUG_TRACE_COMPUTERIZED (0x02)

Switches the file format to the tab separated format. The format is described in the xdebug.trace_format setting as "format 1".

XDEBUG_TRACE_HTML (0x04)

Switches to a file format that shows data as an HTML table.

XDEBUG_TRACE_NAKED_FILENAME (0x08)

With the XDEBUG_TRACE_NAKED_FILENAME flag set, .xt is not added automatically to the end of trace file names.

XDEBUG_TRACE_FLAMEGRAPH_COST (0x10)

Switches to a file format that contains data to create a flame graph visualing CPU time.

XDEBUG_TRACE_FLAMEGRAPH_MEM (0x20)

Switches to a file format that contains data to create a flame graph visualing memory usage.

The XDEBUG_TRACE_FLAMEGRAPH_COST and XDEBUG_TRACE_FLAMEGRAPH_MEM flags are used to create flame graph data. Flame Graphs are described separately.

<?php
xdebug_start_trace("/tmp/xdebug.trace", XDEBUG_TRACE_COMPUTERIZED|XDEBUG_TRACE_NAKED_FILENAME);
?>

The line above creates a file named /tmp/xdebug.trace.

It does not add .xt to the end of the filename (due to XDEBUG_TRACE_NAKED_FILENAME).

The tab-separated trace file format is used due to XDEBUG_TRACE_COMPUTERIZED.

The settings xdebug.collect_assignments, xdebug.collect_params, and xdebug.collect_return influence what information is logged to the trace file and the setting xdebug.trace_format influences the format of the trace file.

The full path and filename to which Xdebug traces is returned from this function. This will be either the filename you pass in (potentially with .xt added), or the auto generated filename if no filename has been passed in.

Stops monitoring functions

This function stops the function monitor. In order to get the list of monitored functions, you need to use the xdebug_get_monitored_functions() function.

Stops the current function trace

Stop tracing function calls and closes the trace file.

The function returns the filename of the file where the trace was written to.