Bug 14607

Summary: -var-list-children reports wrong numchild count
Product: gdb Reporter: Niko Sams <niko.sams>
Component: miAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: niko.sams, tromey
Priority: P2    
Version: 7.5   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Niko Sams 2012-09-22 09:19:11 UTC
To reproduce see this example debug session:

cat main.cpp
#include <vector>

int main()
    struct {
        std::vector<int> a;
    } struct1;


    return 0;

gdb --interpreter=mi2 testdebugee

break main.cpp:12

-var-create struct1 @ struct1

-var-list-children --all-values struct1

-var-list-children --all-values struct1.public
^done,numchild="1",children=[child={name="struct1.public.a",exp="a",numchild="0",value="{...}",type="std::vector<int, std::allocator<int> >",thread-id="1",displayhint="array",dynamic="1"}],has_more="0"
                                                                             ^^^^ should be "2"

-var-list-children --all-values struct1.public.a

-var-info-num-children struct1.public.a
Comment 1 Niko Sams 2012-09-22 09:21:48 UTC
ok the ^^^^ doesn't point where I wanted it to. To be more clear:
Current output:

Expected output:

(after -var-list-children --all-values struct1.public)
Comment 2 Tom Tromey 2022-05-25 19:00:41 UTC
'numchild' isn't reliable for a dynamic varobj.
This is documented in the MI docs:

     The number of children of the varobj.  This number is not
     necessarily reliable for a dynamic varobj.  Instead, you must
     examine the 'has_more' attribute.

This is a little confusing because in this command:

-var-list-children --all-values struct1.public
^done,numchild="1",children=[child={name="struct1.public.a",exp="a",numchild="0",value="{...}",type="std::vector<int, std::allocator<int> >",displayhint="array",dynamic="1"}],has_more="0"

... the has_more here refers to 'struct1.public' (which really only
does have one child), and 'a' doesn't have a has_more here.
Instead one must list the children of 'a' to find out.

So, I'm somewhat inclined to mark this as not a bug.
Comment 3 Tom Tromey 2023-08-31 17:29:03 UTC
Finally came back around to this.
I think it isn't a bug.