Array children inspection limited to 32 child elements #59

michaelfavia opened this Issue Mar 6, 2013 · 7 comments


None yet

4 participants

When inspecting an array you are unable to see the total number of child elements if it exceeds 32. (As is often the case in drupals render arrays).

I have checked my xdebug settings and the xdebug.var_display_max_children=128 but im happy to look anywhere else you'd like to confirm proper setup as well.

Test code I confirmed it with:

$test = array();
for($i=0;$i<100;$i++) {
  $test[] = $i;

Actual result: array inspector shows 32 children
Expected result: Should show all 100

Yeah, I ran into this as well -- takes a long time to figure out your debugger's broken

joonty commented Mar 7, 2013

@michaelfavia thanks for the detailed information.

Yeah, I ran into this as well -- takes a long time to figure out your debugger's broken

@aaronhuckabee that's completely unhelpful. @aaronhuckabee sorry for the misunderstanding :)

Take a look at #55, as it's relevant. @derickr, the author of Xdebug, pointed out that the xdebug INI settings don't relate to the settings for the debugging connection - for that you want features. One of the features you can set is how many children you display, max_children, and you can see all the other features here.

If you upgrade to the latest version of Vdebug (1.4.0) then you can set these features easily in the g:vdebug_features dictionary in your .vimrc:

" Somewhere in your .vimrc after loading vdebug
let g:vdebug_features['max_children'] = 128

Hope that makes sense. Thanks

@joonty: I actually know @aaronhuckabee and forwarded him the issue when i made it so he could follow along as he was similarly affected.

He didn't mean your (joonty) debugger is broken he meant your (his) debugger is broken because he was looking through an associative array and the keys were missing but there was no indication that it was a truncated list of the array so he didnt know it was a configuration error and assumed it was his code. He literally sat there trying to figure out where his array elements were until we finally resorted to print_r() ing them to check to see if his debugger was lying to him. ;)

I think he was just trying to confirm the issue for us. He one of the good guys. ;)

That aside: I was able to load this setting in vim and the debugger worked perfectly (WFM). Thank you for your help and sorry to bring an apparent support request to your queue.

For some reason my Spf13 instance is loading the local modification sources in the wrong order so i cant add it to my .vimrc.local or .vimrc.bundles.fork because the variables havent been defined yet and it causes errors on vim startup but thats an upstream issue i think. spf13/spf13-vim#314

Thanks again.

joonty commented Mar 7, 2013

Completely understood! Sorry for the misunderstanding. Don't worry about bringing a support question - where else are you going to be able to get support for Vdebug anyway? :-P

You've raised a point actually - I think I need to add something to check whether the g:vdebug_features dictionary has already been initialized, so you can use:

let g:vdebug_features = { 'max_children': 128 }

At the moment that won't work if Vdebug gets loaded afterwards, as the dictionary will get overwritten. I'll make that the focus of this issue.


joonty commented Mar 7, 2013

Forgot to reference this issue in the commit name. This is fixed in commit 699ab0e

@joonty joonty closed this Mar 7, 2013

(largely useless comment)
My apologies -- I didn't consider how it sounded before posting, and was only trying to add weight to the issue by confirmation.

Many thanks for the module -- I find it extremely useful.

This particular example of array truncating is worth adding to FAQ - it may save time someone.
I just spent 20 minutes trying to find $_SERVER['REQUEST_URI'].

My english is too poor to add my own patch ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment