View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001222XdebugUncategorizedpublic2015-12-03 15:332016-11-22 23:28
Reporterpounard Assigned Toderick  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionunable to reproduce 
PlatformPHP-FPMOSRedhat, Debian, Archilinux, ...OS VersionAll
Product Version2.4.0beta1 
Summary0001222: [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.

TagsNo tags attached.
Operating System
PHP Version5.6.15-5.6.19

Activities

pounard

2015-12-03 15:37

reporter   ~0003283

Last edited: 2015-12-03 21:13

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.

derick

2015-12-07 10:22

administrator   ~0003291

What was your max packet size set to?

pounard

2015-12-07 16:28

reporter   ~0003298

Last edited: 2015-12-07 16:28

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

derick

2015-12-15 21:39

administrator   ~0003352

Are those settings in eclipse, or do you mean the xdebug.vardisplay* settings?

pounard

2015-12-16 09:25

reporter   ~0003353

Last edited: 2015-12-16 09:26

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.

derick

2016-11-22 23:28

administrator   ~0003781

Hi,

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
this happens.

cheers,
Derick

Issue History

Date Modified Username Field Change
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
2015-12-03 21:12 pounard Note Edited: 0003283
2015-12-03 21:13 pounard Note Edited: 0003283
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
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
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
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized