[xdebug-general] Re: xdebug and geben, property_get

On Sun, 26 Jun 2011, lenneis wrote:

> geben in the default configuration starts out by setting a couple of
> features:
>
> feature_set -i 30000 -n max_data -v 32768
> feature_set -i 30001 -n max_depth -v 1
> feature_set -i 30002 -n max_children -v 32
>
> So we get a maximum of 32 child entries for data structures plus we
> only go down one level and retrieve a maximum size of 32768. If I want
> to look at local/global variables, geben does it like this (output
> omitted for brevity):
>
> context_get -i 30022 -c 0 -d 0
> context_get -i 30023 -c 1 -d 0
>
> That gives me local function variables (-c 0) and global variables (-c
> 1). The returned XML goes only as deep as one level on the data
> structures, but indicates that there are children (children="1" property
> is set) and the number of them (numchildren="n"). Fine. geben uses that
> to show a nice tree display that goes down one level. By clicking on the
> leaf nodes of the tree, you are supposed to drill down further into the
> data structure, but that does not work. In this example, there is a
> local variable, called "$rec". $rec is an object with a property "data"
> which is itself an object (initially not displayed). The XML returned
> for $rec in the context_get from above looks like this (I have deleted
> all other properties apart from "data" to make this shorter):
>
> <property name="rec" fullname="$rec" address="-1257596784" type="object"
> classname="stdClass" children="1" numchildren="24" page="0" pagesize="32">
> [ .... deleted ....]
> <property name="data" fullname="$rec->data" facet="public"
> address="-1257479416" type="object" classname="stdClass" children="1"
> numchildren="3">
> <property name="CLASSNAME" type="string">stdClass</property>
> </property>
> </property>
>
> Hm, why is "CLASSNAME" in there as a property but no other properties? Seems
> to be a special "magic" property, maybe for display purposes.

That has been fixed in the latest versions of Xdebug though (atleast in
the 2.2/master branch).

> When I try to get at the contents of $rec->data, geben issues the
> following DBGB commands:
>
> property_get -i 30024 -d 0 -c 0 -n $rec->data -p 1
> property_get -i 30025 -d 0 -c 0 -n $rec->data -p 2
>
> That does not seem to be the right command. xdebug answers with this:
>
> <response xmlns="urn:debugger_protocol_v1"
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="property_get"
> transaction_id="30024">
> <property name="$rec->data" fullname="$rec->data" address="-1257479416"
> type="object" classname="stdClass" children="1" numchildren="3" page="1"
> pagesize="32">
> <property name="CLASSNAME" type="string">stdClass</property>
> </property>
> </response>
>
> The response is the same for both property_get commands, the only
> difference is that page="1" changes to page="2" for the second reply.

It should really be requesting page 0 (it's a 0-based index) with
"-p 0".

> I then tried this manually (geben gives you a nice CLI window where
> you can issue low level DBGP commands interspersed with regular geben
> commands):
>
> property_get -i 30024 -d 0 -c 0 -n $rec->data -k 1
>
> That works. I now get this:
>
> <response xmlns="urn:debugger_protocol_v1"
> xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="property_get"
> transaction_id="30024">
> <property name="$rec->data" fullname="$rec->data" address="-1257479416"
> type="object" classname="stdClass" children="1" numchildren="3" page="0"
> pagesize="32">
> <property name="CLASSNAME" type="string">stdClass</property>
> <property name="searchresult" fullname="$rec->data->searchresult"
> facet="public" address="-1257596404" type="array" children="1"
> numchildren="13"/>
> <property name="overflow" fullname="$rec->data->overflow" facet="public"
> address="-1257596428" type="bool">0</property>
> <property name="steps_done" fullname="$rec->data->steps_done"
> facet="public" address="-1257596380" type="array" children="1"
> numchildren="4"/>
> </property>
> </response>
>
>
> Which are the actual fields of that object, so that is correct. Is this
> the right way to do this? If yes, what do we need -p for? Also, what is
> the actual semantics of "-k 1"? If I replace "-k 1" with "-k 2", I get
> the exact same result as before, so it does not seem to be an array index.

-k is not used in Xdebug so it's a no-op. -p defaults to 0.

-p is used in case there are more children available than fit in a page
size (numchildren > page_size). So -p 0 will show the first page (first
32 children in your example, because of "-n max_children -v 32") and -p
1 will show you child 33-64 etc.

Hope this helps!

cheers,
Derick

-- 
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
Xdebug | http://xdebug.org | xdebug-general@lists.xdebug.org
twitter: @derickr and @xdebug