[xdebug-general] xdebug and geben, property_get

Dear All,

I am playing around with xdebug (Apache 2, PHP 5.2.17) and use the geben
emacs package as a client. Fascinating stuff, unfortunately geben seems
to be in hibernation at the moment. In trying to get to the bottom of a
geben problem, I have the following question wrt. the DBGP protocol:

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.

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

I tried to find answers to this question in the protocol specification,
but was not clear to me what "-p" and "-k" do precisely. Any help is
much appreciated.

regards,

-- 
Jörg Lenneis