[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [Dltk-dev] exception updating variable children count
|
According to the docs that is controlled by the max_depth and
max_children features.
The features are set to the following values (ScriptThread class):
engine.setMaxChildren(propertyPageSize); //=32
engine.setMaxDepth(2);
engine.setMaxData(8192);
But I don't know if all debuggers use that values.
Probably that values should be configurable.
Regards,
Alex
Johan Compagner wrote:
> javascript seems to be the same, i dont know exactly why but i get
> child counts of 5 or 7 (so not 32 or something)
> but those are not there yet.
> But maybe this happens only for the second page or something. Its a
> bit difficult to know.
>
> And i would like that it would be way more lazy then it is now.
> Because the tree it sends over now is pretty big.
>
> johan
>
>
> On Thu, Jul 10, 2008 at 2:39 PM, Alex Panchenko <alex@xxxxxxxxx
> <mailto:alex@xxxxxxxxx>> wrote:
>
> For large arrays (and similar collection types) initial response
> contains only first page of the results (usually I have seen
> pagesize=32),
> the rest items are filled with nulls and retrieved lazily on demand.
> That is expected.
>
> But python case is different - it reports that there are some
> children, but it does not returned them at all for that "code
> objects".
> Probably that is configurable via some feature, I don't known exactly.
>
> Regards,
> Alex
>
>
> Johan Compagner wrote:
>
> If fixed yesterday something in that area in the
> refreshVariables() methods
>
> There where also cases that numchildren was X (x>0) but the
> children wherent filled.
> But i guess this is just lazy behavior, because that node does
> have children they are just not filled in yet somehow?
> But i dont know if this is expected lazy behavior or not?
>
> ***
> cvs ci -m "fix for null pointer,
> getchildcount of the property can return >0 but the property
> doesnt have to have the AvailableChildren yet loaded in it. i
> guess this is lazy behavior.
> else v.getValue() would result in an value object with
> childs/variables that is en empty array" -l
> "/org.eclipse.dltk.debug/src/org/eclipse/dltk/internal/debug/core/model/ScriptVariable.java"
>
> /cvsroot/technology/org.eclipse.dltk/core/plugins/org.eclipse.dltk.debug/src/org/eclipse/dltk/internal/debug/core/model/ScriptVariable.java,v
> <--
> src/org/eclipse/dltk/internal/debug/core/model/ScriptVariable.java
> new revision: 1.19; previous revision: 1.18
> ok (took 0:00.641)
> ***
>
> johan
>
>
> On Thu, Jul 10, 2008 at 2:05 PM, Alex Panchenko
> <alex@xxxxxxxxx <mailto:alex@xxxxxxxxx> <mailto:alex@xxxxxxxxx
> <mailto:alex@xxxxxxxxx>>> wrote:
>
> Hi Jae,
>
> One of the problems was the parsing of the property
> children nodes
> - nodeName was not checked.
> I have fixed that code.
>
> And another issue is strange numchildren values.
>
> If returns the following context names:
>
> <response xmlns="urn:debugger_protocol_v1"
> command="context_names"
> transaction_id="12">
> <context name="Locals" id="0"/>
> <context name="Globals" id="1"/>
> *
> <context name="Code Objects" id="2"/>*
>
> </response>
>
> We treat 2 as class variables, but here it is "*Code Objects"*,
> and it returns A and B with numchildren=1,
> and getObject() function with numchildren=7 (does it mean
> number
> of lines?).
>
> At the moment I have added code to fill children that were not
> retrieved from the debugger with instances of the
> UnknownVariable.
>
> I don't know what these code objects mean for the python
> developer. Probably we should handle them specially, but that
> should be configured for the python only.
>
> Regards,
> Alex
>
> Jae Gangemi wrote:
>
> hello all -
>
> i keep getting an exception thrown when the code tries to
> update the children count for python objects. i've tracked
> down the issue and it seems that for some values
> returned by
> the python engine, the children count is less than the
> available children count. the ScriptValue object's
> 'variables'
> field is initialized to be the size of
> 'property.getChildrenCount', and 'fillVariables' is
> making a
> call to getAvailableChildren and an
> ArrayOutOfBoundsException
> ends up being thrown b/c the 'variables' array ends up
> being
> too small.
>
> you can see this behavior for yourself by using the
> attached
> python script. just set a breakpoint on line 21 (myobject =
> getObject(1)) and then 'step over'.
>
> the attached patch fixes this behavior by checking to
> see if
> the 'childrenCount' of the dbgp property is less then the
> number of 'availableChildren' (instead of checking to
> see if
> it's less then 0), and if yes, then it sets the
> 'childrenCount' = availableChildren. as far as i can tell,
> this change does not seem to negatively impact any of the
> other debuggers, but perhaps there is a better solution
> for this.
>
> -- -jae
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
> <mailto:dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>>
>
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
> <mailto:dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>>
>
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>