I am trying to analyze what's what in my Yii application by using XDebug paired with PHPStorm. In the "Debug" tool window I can see function calls and the variable list associated with a function call.
There are setting in php.ini that allow xdebug to also collect parameters passed to functions, function return values and also variables that were modified by a particular function.
Is there a way to see all of that in PHPStorm?
The "collect_params" and "collect_returns" extra php.ini settings are for function and stack traces. Xdebug doesn't provide information on which variables where modified by which function. There is information on how to turn on tracing at http://xdebug.org/docs/execution_trace
In PHP Storm, you can easily see the arguments passed to a function by setting a breakpoint on the first line of the function, and inspecting the incoming values. You can also monitor the return value, by setting up a breakpoint at the return statements of the functions that you are interested in. PHP Storm does not allow you to set a break point on a function's entry point and/or exit point - although Xdebug's DBGp protocol does support that: http://xdebug.org/docs-dbgp.php#breakpoints You could file a feature request at https://youtrack.jetbrains.com/dashboard if you want.
Related
I know that xDebug can be enabled (if configured so) to be enabled when a certain cookie is sent along.
I have the case now that a PHP script is being called through a remote server (webhook). Is it possible to enable xDebug through a PHP function call that I can place at the beginning of the PHP file to be called by the webhook?
Or is there any other possibility to enable xDebug for that webhook?
Okay, figured something out.
One can simply append the GET parameter "XDEBUG_SESSION_START" to the URL being called by the webhook to enable xDebug.
Alternatively, assuming you're running Xdebug 3 (which you most likely will be in 2023), and you have access to the xdebug configuration, you can enable start_with_request.
In my setup (IndigoStack) the file is at conf.d/20-xdebug.ini. You need to add the following line:
xdebug.start_with_request=yes
Read more here: https://xdebug.org/docs/upgrade_guide
We are trying to secure a large application (including some third party applications) and we want to disable anything that would allow programmers or potential hackers to hide errors (that is because we are using some monitoring scripts to check the logs in real time and identify any security breach).
We have disabled error_reporting, ini_set (along with some other functions); we have also installed php extension scream to disable suppression operator (no errors are displayed to the user but everything is logged)
We are now looking for a solution to set the default php error_handler server side (instead of using set_error_handler as we do now)? We want to use a custom error handler (for a better logging of the error environment) but we do not want to allow anyone to suppress errors using set_error_handler function.
So basically we can either disable this function (and make sure that all errors will be logged by the default handler) or maybe find a solution to set this server side (maybe an extension or some other trick) for better logging.
Any idea would really help!
UPDATE
We're using Apache with mod_php so we cannot use [PATH] to disable_functions for a certain script. Changing this is not exactly an option.
You can try to use a prepend script which runs before each request
php_value auto_prepend_file prepend.php
In this script you can set the error handler:
<?php
set_error_handler('yourHandler');
/* EOF */
And give only this script the right to use the set_error_handler() function.
i got a script which creates a list implementation of messages being sent between users.
Everything works fine, till the amount of messages rises up to about 77.000.
For every message a object will be created and every object has a reference to the next message object.
I enabled error reporting and increased the memory limit - I don't get any errors and the http status code is a 200 Ok, even if the developer console tells me that the request failed.
If you have verified that it is not a memory limit issue, this could be a limitation of PHP....similar to this question:
How to Avoid PHP Object Nesting/Creation Limit?
If you need to work with 77 000 objects in the same PHP script - it is something wrong with the architecture, php is not right choice for such calculations (even if it can handle this under some circumstances)
to track this particular error try to set in php.ini:
display_errors=1
display_startup_errors=1
error_reporting=-1
log_errors=1
memory_limit=to any reasonable value
max_input_time=to any reasonable value
max_execution_time=to any reasonable value
report_memleaks=1
error_log=writable path
consider using xdebug extension
don't forget to restart apache after changing proper php.ini (you can have different php.ini for apache and cli)
check if any set_error_handler or set_exception_handler functions are called in your code
I'm not sure why, but xdebug does not highlight var_dump(). But config seems to be fine. Have no idea why... Any suggestions?
This is my phpinfo(); http://pastebin.com/A45dqnWN
plus even xdebug_var_dump() doesn't highlight anything. It works, but look like normal var_dump().
I found that option "xdebug.default_enable Off Off" in you php_info(). I also have noticed that in last versions of EasyPHP this option is turned off. So turn it on by setting this line in php.ini:
xdebug.default_enable=1
Next is just common operation which disables var_dump and other errors in HTML output completely (not your case, but maybe helpful for others):
html_errors = On
For Xdebug 3 you need to enable develop mode in your php.ini:
xdebug.mode= develop
You can also use multiple modes at once as explained here.
The following values are accepted (for xdebug.mode):
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 feature, which allows you record every function call, including arguments, variable assignment, and return value that is made during a request to a file.
You can enable multiple modes at the same time by comma separating their identifiers as value to xdebug.mode: xdebug.mode=develop,trace.
As mentioned by #Shadoweb for Xdebug v3 you want debug to allow stopping at breakpoints, and develop to format the var_dump
The following you'll likely want in php.ini therefore:
xdebug.mode=develop,debug
As an aside, I also needed xdebug.start_with_request=yes to replace the renamed xdebug.xdebug.remote_enable=1 setting to get step debugging working in my IDE.
For php 7.0.2 and xdebug 2.4.0
xdebug.default_enable=1
+
html_errors = On
Still does not colorize xdebug_var_dump() output.
but this patch fixes my issue. It applies to the xdebug.c and xdebug_var_dump() only. I think they made a mistake that xdebug_var_dump works only if it need to be overload function.
## -2191,11 +2191,6 ##
int i, len;
char *val;
- if (!XG(overload_var_dump)) {
- XG(orig_var_dump_func)(INTERNAL_FUNCTION_PARAM_PASSTHRU);
- return;
- }
-
argc = ZEND_NUM_ARGS();
#if PHP_VERSION_ID >= 70000
Turn off xdebug.mode=debug in php.ini like
;xdebug.mode=debug
and restart Apache.
We are using xdebug and the tracing works as advertised during code execution via..
function someGetUsersHelper() {
xdebug_start_trace();
[SOME CODE HERE]
xdebug_stop_trace();
}
It however only traces the wrapped part of the code if the page/script is executed via loading the full page in the browser via requesting
index.php
But tracing does not work, when we call the function as an api call via
index.php?api=getUsers
Even though the very same function is executed successfully it does not trace.
As an additional note: Tracing also works if the function is called from phpunit testcases or if we set xdebug.auto_trace = 1 in the php.ini, but that leaves us with a very long, messed up trace file.
So the question is this:
What might be the issue/reason for this and how can we manage to get the
desired clear and succinct trace via api call?
Thanks a lot!!
I could not say why the trace is not working. But you could try this:
Add the option xdebug.trace_enable_trigger=1 in your php configuration
Now you could start a xdebug by adding XDEBUG_TRACE as POST/GET Parameter or as a cookie
There is also a Firefox Plugin called Easy XDebug to set the flags