DBG and Xdebug PHP.ini Directives
DBG php debugger, Copyright © 2001, 2006, Dmitri Dmitrienko
Xdebug php debugger, Copyright © 2002, 2003, 2004 Derick Rethans
PROFILER SETTINGS (Xdebug 1)
This option either enables or disables
the automatic initialization of the
profiler at the start of the script. By
default, automatic is disabled.
PROFILER SETTINGS (Xdebug 1)
Allows you to specify what kind of output
would you like the profiler to generate,
use the integer value used to represent
each profiling mode listed here.
PROFILER SETTINGS (Xdebug 1)
The directory where the profiler output
will be written to, make sure that the
user who the PHP will be running as has
write permissions to that directory. The
created files will look something like
this: xdebug_[timestamp]_[pid].txt.
PROFILER SETTINGS (Xdebug 2)
When this setting is set to 1, profiler files
will not be overwritten when a new request
would map to the same file (depending on the
xdebug.profiler_output_name setting. Instead
the file will be appended to with the new
profile.
PROFILER SETTINGS (Xdebug 2)
Enables Xdebug's profiler which creates
files in the profile output directory.
Those files can be read by KCacheGrind
to visualize your data. This setting can
not be set in your script with ini_set().
PROFILER SETTINGS (Xdebug 2)
When this setting is set to 1, you can
trigger the generation of profiler files
by using the XDEBUG_PROFILE GET/POST
parameter.
PROFILER SETTINGS (Xdebug 2)
The directory where the profiler output
will be written to, make sure that the
user who the PHP will be running as has
write permissions to that directory.
This setting can not be set in your
script with ini_set().
PROFILER SETTINGS (Xdebug 2)
This setting determines the name of the file that
is used to dump profiling information into. The
name of the file always consists of "cachegrind.out.".
This name can be prepended and appended depending
on this setting. Here are four possible values for
this setting:
crc32
The filename will be appended by the crc32 hash
of the current working directory.
Example: cachegrind.out.1224514426
timestamp
The filename will be appended by the current
time as Unix timestamp.
Example: cachegrind.out.1170515030
script
The base name will be prepended by a sanitized
version of the full path to the script's file
name.
Example: tmp_foo_php_cachegrind.out
pid
The base name will be appended by the process
ID of the PHP interpreter (or Apache child)
running the script.
Example: cachegrind.out.30447
SUPERGLOBAL DUMPING SETTINGS
Controls whether the values of the
superglobals should be dumped on all
error situations (set to Off) or only
on the first (set to On).
SUPERGLOBAL DUMPING SETTINGS
If you want to dump
undefined values from the superglobals
you should set this setting to On,
otherwise leave it set to Off.
SUPERGLOBAL DUMPING SETTINGS
These seven settings control which data
from the superglobals is shown when an
error situation occurs. Each php.ini
setting can consist of a comma seperated
list of variables from this superglobal
to dump, but make sure you do not add
spaces in this setting. In order to dump
the REMOTE_ADDR and the REQUEST_METHOD
when an error occurs, add this setting:
xdebug.dump.SERVER = REMOTE_ADDR,REQUEST_METHOD
REMOTE DEBUGGER SETTINGS
Controls which IDE Key Xdebug should
pass on to the DBGp debugger handler. The
default is based on environment settings.
First the environment setting DBGP_IDEKEY
is consulted, then USER and as last USERNAME.
The default is set to the first environment
variable that is found. If none could be
found the setting has as default "".
REMOTE DEBUGGER SETTINGS
Normally you need to use a specific <br><br>
HTTP GET/POST variable to start remote
debugging (see Debugger Usage). When
this setting is set to "On" Xdebug will
always attempt to start a remote debugging
session and try to connect to a client,
even if the GET/POST/COOKIE variable
was not present.
REMOTE DEBUGGER SETTINGS
This switch controls whether Xdebug
should try to contact a debug client
which is listening on the host and port
as set with the settings 'xdebug.
remote_host' and 'xdebug.remote_port'.
If a connection can not be established
the script will just continue as if this
setting was Off.
REMOTE DEBUGGER SETTINGS
Can be either 'php3' which selects the
old PHP 3 style debugger output, or
'gdb' which enables the GDB like
debugger interface. As there is
currently no bundled client for the PHP
3 style debugger and because it's much
less powerful then the GDB like one,
it is advised to leave this setting to
'gdb'.
REMOTE DEBUGGER SETTINGS
Selects the host where the debug client
is running, you can either use a host
name or an IP address.
REMOTE DEBUGGER SETTINGS
If set to a value, it is used as filename to a
file to which all remote debugger communications
are logged.
REMOTE DEBUGGER SETTINGS
Selects between the 'req' and 'jit'
debugging modes for the 'gdb' handler.
If it is set to 'req' (the default)
then Xdebug will try to connect to the
debug client as soon as the script
starts. If it is set to 'jit' it will
only try to connect as soon as an error
condition occurs.
REMOTE DEBUGGER SETTINGS
The port to which Xdebug tries to
connect on the remote host. As the
bundled debug client only listens at
the hard coded port 17689 (9000 for
latest version) you should leave this
setting unchanged.
TRACING SETTINGS
When this setting is set to on, the
tracing of function calls will be enabled
just before the script is run. This makes
it possible to trace code in the
auto_prepend_file.
TRACING SETTINGS (Xdebug 2)
This setting, defaulting to On, controls
whether Xdebug should write the filename
used in include(), include_once(), require()
or require_once() to the trace files.
TRACING SETTINGS
This setting, defaulting to Off, controls
whether Xdebug should collect the parameters
passed to functions when a function call is
recorded in either the function trace or the
stack trace. It defaults to Off because for
very large scripts it may use huge amounts
of memory and therefore make it impossible
for the huge script to run. You can most
safely turn this setting on, but you can expect
some problems in scripts with a lot of
functioncalls and/or huge data structures as
parameters. Xdebug 2 will not have this problem
with increased memory usage, as it will never
store this information in memory. Instead it
will only be written to disk. This means that
you need to have a look at the disk usage
though.
TRACING SETTINGS (Xdebug 2)
This setting, defaulting to Off, controls
whether Xdebug should write the return value
of function calls to the trace files.
TRACING SETTINGS (Xdebug 2)
When set to "1" the trace files will be
appended to, instead of being overwritten
in subsequent requests.
TRACING SETTINGS (Xdebug 2)
The directory where the tracing files will
be written to, make sure that the user who
the PHP will be running as has write
permissions to that directory.
TRACING SETTINGS (Xdebug 2)
When set to "crc32" the middle part of a
trace file name will be a crc32 hash of
the current working directory, in all other
cases the Process ID of the PHP process is
used here.
GENERAL SETTINGS
This setting tells Xdebug to gather information
about which variables are used in a certain scope.
This analysis can be quite slow as Xdebug has to
reverse engineer PHP's opcode arrays. This setting
will not record which values the different variables
have, for that use xdebug.collect_params.
GENERAL SETTINGS
If this setting is On then stacktraces will be shown by default
on an error event. You can disable showing stacktraces from your
code with xdebug_disable(). As this is one of the basic functions
of Xdebug, it is advisable to leave this setting set to 'On'.
An example error message may look like:
Warning: Wrong parameter count for
str_replace() in
/home/httpd/html/test/xdebug_error.php
on line 5
Call Stack
# Function Location
1 {main}() /home/httpd/html/test/xdebug_error.php:0
2 fix_string('Derick') /home/httpd/html/test/xdebug_error.php:8
3 str_replace ('a', 'b') /home/httpd/html/test/xdebug_error.php:5
GENERAL SETTINGS
Controls whether Xdebug should enforce
"extended_info" mode for the PHP parser;
this allows Xdebug to do file/line breakpoints
with the remote debugger. When tracing or
profiling scripts you generally want to turn
off this option as PHP's generated oparrays
will increase with about a third of the
size slowing down your scripts. This
setting can not be set in your scripts with
ini_set(), but only in php.ini.
GENERAL SETTINGS
This is the base url for the links from the
function traces and error message to the manual
pages of the function from the message. It is
advisable to set this setting to use the closest
mirror.
PROFILER SETTINGS (Xdebug 2)
Controls the protection mechanism for
infinite recursion protection. The value
of this setting is the maximum level of
nested functions that are allowed before
the script will be aborted.
DISPLAY SETTINGS
When this setting is set to 1, Xdebug will show
a stack trace whenever an exception is raised -
even if this exception is actually caught.
DISPLAY SETTINGS
When this setting is set to something != 0
Xdebug's generated stack dumps in error
situations will also show all variables in
the top-most scope. Beware that this might
generate a lot of information, and is therefore
turned off by default.
DISPLAY SETTINGS
When this setting is set to something
!= 0 Xdebug's human-readable generated
trace files will show the difference in
memory usage between function calls. If
Xdebug is configured to generate computer-
readable trace files then they will always
show this information.
DISPLAY SETTINGS
Controls the amount of array children and
object's properties are shown when variables
are displayed with either xdebug_var_dump()
or xdebug,show_local_vars
DISPLAY SETTINGS
Controls the maximum string length that is shown
when variables are displayed with either
xdebug_var_dump() or xdebug,show_local_vars.
DISPLAY SETTINGS
Controls how many nested levels of array elements
and object properties are shown when variables are
displayed with either xdebug_var_dump() or xdebug,
show_local_vars.