View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001222||Xdebug||Usage problems (Wrong Results)||public||2015-12-03 15:33||2016-11-22 23:28|
|Status||resolved||Resolution||unable to reproduce|
|Platform||PHP-FPM||OS||Redhat, Debian, Archilinux, ...||OS Version||All|
|Target Version||Fixed in Version|
|Summary||0001222: [2.1, 2.2, 2.3, 2.4] Xdebug attempt a memory allocation so big that the linux kernel will kill it|
|Description||When working in project, I was able to reproduce this problem with many software: Symfony 2 when debugging into the security component, Drupal when debugging into the views module obscure code, and a few other cases.|
Generally speaking, when you have an huge stack trace, followed by a lot of objects in the current scope, and those objects references each other in a lot of ways, and you have a breakpoint there, this happens.
Symptoms is that Xdebug attempt to malloc so much memory at once that the linux kernel decides to kill the PHP-FPM process without any further judgement, there is no log, anywhere.
While watching the xdebug remote debug log, it remains silent for this breakpoint in particular (the other are OK).
While watching the fpm log, nothing happens, fpm process is just killed.
While watchdog the syslog, nothing happens in there too.
The browser just tells that the server does not respond.
And, while dmesg'ing, tada:
Out of memory: Kill process 28095 (php-fpm) score 691 or sacrifice child Killed process 28095, UID 1000, (php-fpm) total-vm:3229368kB, anon-rss:1567852kB, file-rss:5576kB
This one was a nice one, Xdebug only attempted to malloc 1.5GB, but it went over to 3GB at once.
|Steps To Reproduce||I have no clear steps to reproduce, just download a huge framework with a working huge application on it, add a breakpoint anywhere you know there's a lot of objects referencing each other, and step into it.|
|Additional Information||This happens since the 2.1 or 2.2 version, can't remember exactly when, but it's a long standing issue I have. I don't have any log anywhere, since the process is killed by the kernel itself, no log except the dmesg one.|
I just tested with 2.4.0-RC2, still the same problem.
It also happens from PHP 5.3 to 5.6 the exact same way, with various combinations of Xdebug/PHP versions.
I use Eclipse/PDT as the debugging client, until know I always thought that Eclipse was the problem, until I found out that I was able to configure its own accepted maximum packet size limit, which I did. Before that, the problem was the same except that PHP and Eclipse were both on their respective boxes taking 100% CPU until both died a few minutes later. Now that I raised Eclipse own configuration to something huge, the dying process is almost instantaneous.
I would be please to give you more information, debug stack trace, etc... But I'll need you to tell me how to generate the information you need.
|Tags||No tags attached.|
Actually, I changed the Eclipse/PDT debugger maximum packet size back a very small value, and Xdebug does not crashes anymore, I don't know which magic does happen... This might not be an Xdebug bug in the end, but wrong default values for the PDT debugger configuration.
For I don't know nothing about the DBGP protocol nor anything about the PDT internals, I suspect the debugger client side (PDT) is the cause asking too much at once to the Xdebug about the context. I'll be pleased to go and read the PDT code or give you more information if you wish, but since the bug don't occur anymore, you may close this issue.
||What was your max packet size set to?|
Original value was 1024 bytes, I raised it to 32768, now it's 2048 and working fine.
Other related settings you might want to know:
* Max array depth: was set to 10 per default, is now 8
* Max children: can't remember the default value, is now 32
||Are those settings in eclipse, or do you mean the xdebug.var_display_* settings?|
These are the Eclipse Xdebug connector settings, as I said, I don't much about how it internally works. You may also want to know that I always leave the Xdebug configuration per default (except host and port settings).
I might add that since I changed those settings, it works in 99% of cases, but sometime, it happens than when I'm playing too much with the stack trace (trying to navigate in it in order to do some real debugging) it happens that Eclipse starts again eating 100% of my CPU, and Xdebug almost always crashes along the way with the symptoms I described upper, but it seems to be much more difficult to reproduce now.
Nevertheless I noticed that the lower are the configuration values (the max array depth mainly) the slower is the debug interface, and I'm not sure this is really Eclipse being slow because when values are up, it's lightening fast but makes Xdebug crashes more often.
There's I guess somewhere some kind of trade-off to find between speed and memory consumption, but there's definitely something that makes Xdebug unhappy, and I really don't know if it's Eclipse or Xdebug itself.
I am closing this as no specific problem was identified, nor can I reproduce
this. Feel free to reopen this if you have more information how and when
|2015-12-03 15:33||pounard||New Issue|
|2015-12-03 15:37||pounard||Note Added: 0003283|
|2015-12-03 21:10||pounard||Note Edited: 0003283||View Revisions|
|2015-12-03 21:12||pounard||Note Edited: 0003283||View Revisions|
|2015-12-03 21:13||pounard||Note Edited: 0003283||View Revisions|
|2015-12-07 10:22||derick||Note Added: 0003291|
|2015-12-07 16:28||pounard||Note Added: 0003298|
|2015-12-07 16:28||pounard||Note Edited: 0003298||View Revisions|
|2015-12-15 21:39||derick||Note Added: 0003352|
|2015-12-15 21:39||derick||Assigned To||=> derick|
|2015-12-15 21:39||derick||Status||new => feedback|
|2015-12-16 09:25||pounard||Note Added: 0003353|
|2015-12-16 09:25||pounard||Status||feedback => assigned|
|2015-12-16 09:26||pounard||Note Edited: 0003353||View Revisions|
|2016-07-31 12:36||derick||Category||Usage problems => Usage problems (Crashes)|
|2016-07-31 12:38||derick||Category||Usage problems (Crashes) => Usage problems (Wrong Results)|
|2016-11-22 23:28||derick||Note Added: 0003781|
|2016-11-22 23:28||derick||Status||assigned => resolved|
|2016-11-22 23:28||derick||Resolution||open => unable to reproduce|