According to this article, http://devzone.zend.com/article/2803, var_dump is supposed to beautify the outputs.
I have installed xdebug on my local host with PHP Version 5.3.3-1ubuntu9.2.
I have this in my php.ini outputs.
This program makes use of the Zend
Scripting Language Engine: Zend Engine
v2.3.0, Copyright (c) 1998-2010 Zend
Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
However when I use var_dump(), nothing changes.
Does xdebug really beautify the var_dump outputs?
If so, how can I fix it?
This is my details of xdebug in php.ini
xdebug
xdebug support enabled
Version 2.1.0
Supported protocols Revision
DBGp - Common DeBuGger Protocol $Revision: 1.145 $
Directive Local Value Master Value
xdebug.auto_trace Off Off
xdebug.collect_assignments Off Off
xdebug.collect_includes On On
xdebug.collect_params 0 0
xdebug.collect_return Off Off
xdebug.collect_vars Off Off
xdebug.default_enable On On
xdebug.dump.COOKIE no value no value
xdebug.dump.ENV no value no value
xdebug.dump.FILES no value no value
xdebug.dump.GET no value no value
xdebug.dump.POST no value no value
xdebug.dump.REQUEST no value no value
xdebug.dump.SERVER no value no value
xdebug.dump.SESSION no value no value
xdebug.dump_globals On On
xdebug.dump_once On On
xdebug.dump_undefined Off Off
xdebug.extended_info On On
xdebug.file_link_format no value no value
xdebug.idekey netbeans-xdebug netbeans-xdebug
xdebug.manual_url http://www.php.net http://www.php.net
xdebug.max_nesting_level 100 100
xdebug.overload_var_dump On On
xdebug.profiler_aggregate Off Off
xdebug.profiler_append Off Off
xdebug.profiler_enable On On
xdebug.profiler_enable_trigger Off Off
xdebug.profiler_output_dir /tmp /tmp
xdebug.profiler_output_name cachegrind.out.%p cachegrind.out.%p
xdebug.remote_autostart Off Off
xdebug.remote_connect_back Off Off
xdebug.remote_cookie_expire_time 3600 3600
xdebug.remote_enable On On
xdebug.remote_handler dbgp dbgp
xdebug.remote_host localhost localhost
xdebug.remote_log no value no value
xdebug.remote_mode req req
xdebug.remote_port 9000 9000
xdebug.scream Off Off
xdebug.show_exception_trace Off Off
xdebug.show_local_vars Off Off
xdebug.show_mem_delta Off Off
xdebug.trace_format 0 0
xdebug.trace_options 0 0
xdebug.trace_output_dir /tmp /tmp
xdebug.trace_output_name trace.%c trace.%c
xdebug.var_display_max_children 128 128
xdebug.var_display_max_data 512 512
xdebug.var_display_max_depth 3 3
Thanks in advance.
You need to have html errors turned on in your php config as well
Related
I need to debug an PHP application running on a Apache 2 web-server.
But Xdebug doesn't seam to do anything at all; the config is loaded correctly as I can seen in my phpinfo().
zend_extension=xdebug.so
[debug]
xdebug.profiler_enable_trigger = 0
xdebug.profiler_enable = 1
#xdebug.remote_enable = 1
xdebug.profiler_output_dir = "/tmp"
#xdebug.client_host = ip-of-my-desktop
#xdebug.log = "/tmp/xdebug.log"
#xdebug.default_enable = 1
#xdebug.discover_client_host = 1
xdebug.log_level = 10
xdebug.log = "debug"
xdebug.output_dir = /tmp
I tried many combinations but nothing worked.
No profile file are generated an no one tried to connect to my machine on port 90000.
The xdebug.log line had also no effect, no file has been created.
Thanks for your help, I am running out of ideas I managed to get it to work on Debian 9 machine.
xdebug part from phpinfo()
Development Aids ✔ enabled 🖹
Coverage ✘ disabled 🖹
GC Stats ✘ disabled 🖹
Profiler ✘ disabled 🖹
Step Debugger ✘ disabled 🖹
Tracing ✘ disabled 🖹
Directive Local Value Master Value
xdebug.auto_trace (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.cli_color 0 0
xdebug.client_discovery_header no value no value
xdebug.client_host localhost localhost
xdebug.client_port 9003 9003
xdebug.cloud_id no value no value
xdebug.collect_assignments Off Off
xdebug.collect_includes (setting removed in Xdebug 3) (setting removed in Xdebug 3)
xdebug.collect_params (setting removed in Xdebug 3) (setting removed in Xdebug 3)
xdebug.collect_return Off Off
xdebug.collect_vars (setting removed in Xdebug 3) (setting removed in Xdebug 3)
xdebug.connect_timeout_ms 200 200
xdebug.coverage_enable (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.default_enable (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.discover_client_host Off Off
xdebug.dump.COOKIE no value no value
xdebug.dump.ENV no value no value
xdebug.dump.FILES no value no value
xdebug.dump.GET no value no value
xdebug.dump.POST no value no value
xdebug.dump.REQUEST no value no value
xdebug.dump.SERVER no value no value
xdebug.dump.SESSION no value no value
xdebug.dump_globals On On
xdebug.dump_once On On
xdebug.dump_undefined Off Off
xdebug.file_link_format no value no value
xdebug.filename_format no value no value
xdebug.force_display_errors Off Off
xdebug.force_error_reporting 0 0
xdebug.gc_stats_enable (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.gc_stats_output_dir (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.gc_stats_output_name gcstats.%p gcstats.%p
xdebug.halt_level 0 0
xdebug.idekey no value no value
xdebug.log debug debug
xdebug.log_level 10 10
xdebug.max_nesting_level 256 256
xdebug.max_stack_frames -1 -1
xdebug.mode develop develop
xdebug.output_dir /tmp /tmp
xdebug.overload_var_dump (setting removed in Xdebug 3) (setting removed in Xdebug 3)
xdebug.profiler_append Off Off
xdebug.profiler_enable (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.profiler_enable_trigger (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.profiler_enable_trigger_value (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.profiler_output_dir (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.profiler_output_name cachegrind.out.%p cachegrind.out.%p
xdebug.remote_autostart (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_connect_back (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_enable (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_host (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_log (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_log_level (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_mode (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_port (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.remote_timeout (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.scream Off Off
xdebug.show_error_trace Off Off
xdebug.show_exception_trace Off Off
xdebug.show_local_vars Off Off
xdebug.show_mem_delta (setting removed in Xdebug 3) (setting removed in Xdebug 3)
xdebug.start_upon_error default default
xdebug.start_with_request default default
xdebug.trace_enable_trigger (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.trace_enable_trigger_value (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.trace_format 0 0
xdebug.trace_options 0 0
xdebug.trace_output_dir (setting renamed in Xdebug 3) (setting renamed in Xdebug 3)
xdebug.trace_output_name trace.%c trace.%c
xdebug.trigger_value no value no value
xdebug.var_display_max_children 128 128
xdebug.var_display_max_data 512 512
xdebug.var_display_max_depth 3 3
PS: I installed the package php-xdebug
PPS: Xdebug v3.0.2
I am uncertain why this is working now.
Now I have this config.
xdebug.mode="debug"
xdebug.trigger_value="XDEBUG_ECLIPSE"
xdebug.start_with_request="yes"
xdebug.client_host="myip"
Cookies and environment variables did not change anything.
I am using lando (v3.0.0.rc-14) along with docker CE (latest version) for my Drupal 7 site. I am trying to import database of file size uncomressed(~4GB) & compressed (~900 MB) using following command:
lando db-import db-name db-filename.sql
lando db-import db-name db-filename.sql.gz
But, this is not helping. Usually, this db-import is taking more than 24 hours to complete. Is this a problem with my version or my settings in .lando.yml file?
My CPU and Mem usage stats below:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28334 1001 20 0 1435088 568912 15892 S 2.3 3.5 4:27.81 mysqld
3131 usersf 20 0 306928 9320 7172 S 1.7 0.1 0:38.15 gvfs-udisks2-vo
2095 root 20 0 2434900 96804 39620 S 1.3 0.6 0:34.19 dockerd
Try these instructions
Disable writing barrier for the ext4 fs:
$ sudo gedit /etc/fstab
Here you’ll see something like this:
UUID=700a2404-f687-4ae2-a2d5-54291553551e / ext4 errors=remount-ro 0 1
So you just need to add barrier=0
UUID=700a2404-f687-4ae2-a2d5-54291553551e / ext4 errors=remount-ro,barrier=0 0 1
Reboot your system.
Or try any of the suggestions
I'm debugging remotely my project in PhpStorm. IDE shows 'Connected' for a moment and immediately goes into 'Waiting for incoming connection...'
Below is Xdebug log from this session
I: Connecting to configured address/port: X.x.x.x:9000.
I: Connected to client. :-)
> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///xxx/info.php" language="PHP" protocol_version="1.0" appid="4365" idekey="10594"><engine version="2.2.2"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATAhttp://xdebug.org]></url><copyright><![CDATA[Copyright (c) 2002-2013 by Derick Rethans]]></copyright></init>
<- feature_set -i 0 -n show_hidden -v 1
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="0" feature="show_hidden" success="1"></response>
<- feature_set -i 1 -n max_depth -v 1
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="1" feature="max_depth" success="1"></response>
<- feature_set -i 2 -n max_children -v 100
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="2" feature="max_children" success="1"></response>
<- status -i 3
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="status" transaction_id="3" status="starting" reason="ok"></response>
<- step_into -i 4
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="4" status="stopping" reason="ok"></response>
<- breakpoint_set -i 5 -t line -f file://xxx/info.php -n 3
> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="5"><error code="5"><message><![CDATA[command is not available]]></message></error></response>
"
According to Xdebug documentation status "stopping" is
'State after completion of code execution. This typically happens at the end of code execution, allowing the IDE to further interact with the debugger engine (for example, to collect performance data, or use other extended commands).'
So my debugger stops before reaching first breakpoint (set on first line).
Could it be a question of server configuration?
You should go to php.ini and delete a line like this
extension=php_xdebug-...
How did this line was created.
You put a xdebug's file into PHP extensions path like this
.../php5.X.XX/ext/
Now you may turn on this PHP extension by any _AMP UI tools like WAMP, XAMPP etc.
To prevent this painful misfortune you must put the Xdebug file into
.../php5.X.XX/zend_ext/
It'll make Xdebug hidden from any _AMP tool.
And correct your zend_extension parameter too.
zend_extension = .../php5.X.XX/ext/php_xdebug-...
to
zend_extension = .../php5.X.XX/zend_ext/php_xdebug-...
It's common default path for it.
Please, remember!
With PHPStorm, Eclipse, Zend etc., possibly you should consider to correct two php.ini files.
The first one for your web server. Commonly under Apache folder
...\Apache2.X.XX\bin\
The second one is for the direct PHP-script debugging. It lies in the PHP hosting folder:
...\php\php5.X.XX\
In my case, the cause of the "breakpoint_set" / "command is not available" problem was disabled xdebug.extended_info option (it is enabled by default but I disabled it for profiling).
Breakpoints do not work then xdebug.extended_info is disabled.
I have got breakpoints worked after reenabling xdebug.extended_info.
I had same problem under windows, with phpstorm, i was googling many time. Eventually, my decision is the:
in php.ini:
xdebug.remote_mode = "jit"
From phpstorm tutorial, JIT - "Just-In-Time" Mode
https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html#d43035e303
UPD
No, this option does not helped me actually. But, i resolve my issue in the end:
I use phpstrom for win 7, and i configured the path mapping this way:
d:\serverroot\vhost\www => d:\serverroot\vhost\www
but in my old config i spied such mapping:
d:\serverroot\vhost\www => d:/serverroot/vhost/www
Finally
On windows machines in path mapping in server configuration replace the \ by /
I think the only reason why this could happen is that your info.php has a syntax error. In that case, there is no code to execute and the script goes directly to "stopping" upon issue of the "step_into".
Zend_Opcache / OPCache can cause this issue as well, if you have it enabled try disabling it.
This error can be emitted when the XDebug extension is compiled into a non-debug build of the PHP runtime. The process will not fail (as it shouldn't), but the XDebug extension will stop doing anything for the duration of that process
Why xdebug don't show error trace and var_dump (only php standatr error output)? But debuging is working.
I am working n Mac OS Lion.
Here is my configuration:
[xdebug]
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
; Remote settings
xdebug.remote_autostart=off
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000
; General
xdebug.show_local_vars=On
xdebug.dump.SERVER=HTTP_HOST, SERVER_NAME
xdebug.dump_globals=On
xdebug.collect_params=4
xdebug.auto_trace=off
xdebug.collect_includes=on
xdebug.collect_return=off
xdebug.default_enable=on
xdebug.extended_info=1
xdebug.manual_url=http://www.php.net
xdebug.show_mem_delta=1
xdebug.max_nesting_level=100
xdebug.idekey=xdebug
; Trace options
xdebug.trace_format=0
xdebug.trace_output_dir=/tmp/xdebug/trace
xdebug.trace_options=0
xdebug.trace_output_name=tracelog
; Profiling
xdebug.profiler_append=0
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=/tmp/xdebug/debug
xdebug.profiler_output_name=scriptprofile.out
Make sure to have html_errors set to on (1) in php.ini as well. This is for some odd reason turned off by default in PHP 5.3. In PHP 5.4, the default is on (1) again.
Occasionally mod_perl apache process is marked "defunct" in "top" utility, that is becomes a zombie process.
Is it a correct behavior?
Do I have to worry about it?
Our Perl script is very simple, it does not spawn any child processes.
The zombie process disappears pretty quickly.
Apache2, Ubuntu.
Our apache config is here: apache_config.txt
Here is a snap-shot of top.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19525 www-data 20 0 55972 25m 4684 S 10.3 2.4 0:00.32 apache2
19486 www-data 20 0 52792 21m 4120 S 1.7 2.1 0:00.05 apache2
19538 www-data 20 0 52792 21m 4120 S 1.3 2.1 0:00.04 apache2
19539 www-data 20 0 0 0 0 Z 0.7 0.0 0:00.03 apache2 <defunct>
19481 www-data 20 0 52860 21m 4016 S 0.3 2.1 0:00.05 apache2
19521 www-data 20 0 52804 21m 3824 S 0.3 2.1 0:00.08 apache2
These are CPAN modules I use
CGI();
XML::LibXML();
DateTime;
DateTime::TimeZone;
Benchmark();
Data::Dump();
Devel::StackTrace();
DBD::mysql();
DBI();
LWP();
LWP::UserAgent();
HTTP::Request();
HTTP::Response();
URI::Heuristic();
MD5();
IO::String();
DateTime::Format::HTTP();
Math::BigInt();
Digest::SHA1();
top:
26252 www-data 20 0 0 0 0 Z 0.3 0.0 0:00.22 apache2 <defunct>
access.log with pid logged as the first parameter:
26252 85.124.207.173 - - [26/Dec/2009:22:16:42 +0300] "GET /cgi-bin/wimo/server/index.pl?location=gn:2761369&request=forecast&client_part=app&ver=2_0b191&client=desktop&license_type=free&auto_id=125CC6B6DAA HTTP/1.1" 200 826 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB6.3; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
3 different zombie processes logged by server-status
Srv PID Acc M CPU SS Req ConnChild Slot Client VHost Request
32-0 1300 0/0/45 _ 0.00 0 0 0.0 0.00 2.29 127.0.0.1 weather_server OPTIONS * HTTP/1.0
100-0 1254 1/7/41 C 0.22 0 0 0.0 0.00 1.51 127.0.0.1 weather_server OPTIONS * HTTP/1.0
29-0 1299 0/12/78 _ 0.31 0 2 0.0 0.78 2.37 [my ip was here] weather_server GET /server-status HTTP/1.1
My first suspicion is that you really are forking but maybe you don't realize it. Is it possible for to include your code? Remember that any system or `` calls are forking. This could easily be happening inside a CPAN module without you realizing. There is some useful information about mod_perl and forking (including how zombies are created and how to avoid them) here.
Update: try adding this to your config:
# Monitor apache server status
ExtendedStatus On
<VirtualHost 127.0.0.1:80>
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
</VirtualHost>
And then change the Allow from to be your IP, then you can visit http://yourdomain.com/server-status and get a page of summary information on apache. Try doing this when you see one of the zombies and look to see what apache thinks that process is doing.
I see that too with my very simple mod_perl 2 module. I do not fork anything, just write a string to client socket and then return OK. And still a defunct process appears at my CentOS 5.5 Linux VM and then goes away. Here is my source code and you can test it with "telnet yourhost 843" and pressing ENTER:
package SocketPolicy;
# Run: semanage port -a -t http_port_t -p tcp 843
# And add following lines to the httpd.conf
# Listen 843
# <VirtualHost _default_:843>
# PerlModule SocketPolicy
# PerlProcessConnectionHandler SocketPolicy
# </VirtualHost>
use strict;
use warnings FATAL => 'all';
use APR::Const(-compile => 'SO_NONBLOCK');
use APR::Socket();
use Apache2::ServerRec();
use Apache2::Connection();
use Apache2::Const(-compile => qw(OK DECLINED));
use constant POLICY =>
qq{<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" to-ports="8080"/>
</cross-domain-policy>
\0};
sub handler {
my $conn = shift;
my $socket = $conn->client_socket();
my $offset = 0;
# set the socket to the blocking mode
$socket->opt_set(APR::Const::SO_NONBLOCK => 0);
do {
my $nbytes = $socket->send(substr(POLICY, $offset), length(POLICY) - $offset);
# client connection closed or interrupted
return Apache2::Const::DECLINED unless $nbytes;
$offset += $nbytes;
} while ($offset < length(POLICY));
my $slog = $conn->base_server()->log();
$slog->warn('served socket policy to: ', $conn->remote_ip());
return Apache2::Const::OK;
}
1;