Twig dump crashes site/server with out of memory

Dump is just var_dump so yeah it will run out of memory. I recommend kint from devel instead.

@hass
Please be nice to people, as you want the same from them. Your assumption that kint() is not available from within templates is wrong, see http://cgit.drupalcode.org/devel/tree/kint/src/Twig/KintExtension.php.

@Cottser
What about also replacing dump() from within the kint module, just to have both things available?

@hass
I won't answer your comment, due to your niceness.

@hass if you want dump "fixed" (as I said it's just var_dump so not sure what you're going to change) you're going to have to file an upstream bug with Twig.

@dawehner not sure what you mean by replacing dump - make dump do kint when kint is installed?

@dawehner not sure what you mean by replacing dump - make dump do kint when kint is installed?

Exactly.

Related maybe: #1804998: Add LadyBug from Symfony to Core to allow debugging variables within templates

@webchick, @alexpott, @catch, @effulgentsia and I agreed that this is a normal priority issue.

I'd rather not magically change dump() to kint() when kint is installed, it feels too magical. What if you have kint installed but still want to use dump() for some reason?

IMO this should still be closed won't fix like I said in #4. This is not a Drupal issue, it's a PHP issue if anything, not even Twig. I could be wrong but I'm fairly sure the exact same thing would happen if you had the same object(s) in PHPTemplate and ran var_dump() on them.

Anyway, even kint() returns the memory exhausted error when I've tried to debug the ECK twig template.

yes, even kint() does same. Any update on it?

There has been documentation for this in the Theming guide.
https://www.drupal.org/docs/8/theming/twig/discovering-and-inspecting-va...

Feel free to re-open if you have a solution to deal with this, closing to triage. #14 needs addressing

The best "workaround" for that kind of problem is to simple use the right tool for the job aka. a debugger.

@hass no - this isn't Drupal specific. Symfony has the same problem as well depending on what you dump. Ladybug is what most symfony people advise to use. There's even a Drupal extension at https://www.drupal.org/project/ld - although I haven't tested it yet.

There is also https://www.drupal.org/project/vardumper for it

I got the same issue, as a developer just wish to template a view tpl, it's very expensive to use kint or dump. site went to down after I try to dump the variables. I am not the frontend dev, so how is the fast way to see the variables

I believe the memory limit issue is related to recursions ( see https://www.drupal.org/node/2277303#comment-11168509 ). Krumo used to just print an infinity sign and move along; however, Kint goes deeper into arrays/objects which eventually maxes out the PHP memory limit.

The good news is that there is a request to add a UI to Kint to set the max-levels (see https://www.drupal.org/node/2405179 ). Until then a good workaround is to make sure your memory level is at 1024M and patch ~line 78 of /modules/contrib/devel/kint/kint/config.default.php so that it says $_kintSettings['maxLevels'] = 5;. The default level is 7.

thx Peezy, it good to know.

@hass Depending on how deep you want to go, try something like kint(page|keys) or dump(page|keys).

Oops! Sorry, I got here by searching for my error and neglected to thoroughly review the issue description (insert face palm here).

This may work:

Because Twig uses the PHP var_dump function internally, try installing xdebug, which limits the var_dump() output of arrays and objects to 3 levels deep.

Or use vardumper() instead of dump() and kint(), with the twig_vardumper module.

@Peezy:

Thank you so much about pointing out the max levels setting for kint. You saved me a lot of headaches with that info as I don't have xdebug set up yet.

I was facing the same issue.

We can't dump a large amout of data or a complete array in Drupal 8. This is an issue. But there is a solution as well, either we should know the exact key name or machine name of the variable or filed we want to print. Or we can print the keys existing the array. That could be helpful or us. For this we can use dump function syntax for dump is {{ dump(_context|keys ) }} or we should go for kint function which is useful to understand the elements with a good UI look of the dump. For this we enable devel module. Syntax for kint it {{ kint() }}. Here i am giving few dumping examples which can be usefull to come up with the problem of dumping.

Discovering all available variables in a template

To dump all available variables and their contents in a template, add the following to your template (after enabling debugging):

{{ dump() }} -->It could give a memory error if the amount of data is large.

To dump only the available variable keys use:

{{ dump(_content|keys) }} -->Play with this , get the keys and use them instead.

Beware of dump()

If you want to see all variables, but dump() results in exhausted memory because of recursion or the like, you can loop through _context to see all the keys in it:

<ol>
  {% for key, value in _context  %}
    <li>{{ key }}</li>
  {% endfor %}
</ol>  -->This could be also a solution.

I Hope this solution helps you.

This problem occurs because the array is self-referencing in nature. The solution is in a preprocess function:

$links = json_decode(json_encode($variables['links']));
//or
$links = unserialize(serialize($variables['links']));
var_dump($links);

Gist with a workaround until there is a setting in devel one day perhaps to override kint defaults cleanly:
https://gist.github.com/JPustkuchen/a5f1eaeb7058856b7ef087b028ffdfeb

If you have xdebug installed, you can override some of the settings in php.ini, to be a bit more memory friendly. Max Depth seems to be the biggest culprit, if I go above 8 I start hitting issues.

I've found success with the following on local environment with 1GB limit.

[xdebug]
xdebug.var_display_max_children = 128
xdebug.var_display_max_data = 1024
xdebug.var_display_max_depth = 8