Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] exception updating variable children count

but what will happen if there are less?
the problem is that the chlid count is taken from a request that did happen in the past
and then it is filled with something from the present
somehow this should be done better
But i dont know that component good enough to understand it completely

for example by default i think the scriptengine gets way to many children in the variable view.
It should just go 1 deep what you see and then only ask IF there are children and populate those and only those when ask for (user clicks on it)

johan


On Mon, Jul 28, 2008 at 4:11 PM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  i'm still seeing this behavior in some instances.

  i've come up with another patch that checks to see if the size of the 'variables' array has been exceeded when it is populated in the 'fillVariables' method - if it has, we just stop populating the array. does anyone see issues w/ this? if not, i'll commit and include an 'else' block to log when this event occurs so it can at least be tracked and not cause the view to blow up anymore.



On Thu, Jul 10, 2008 at 9:30 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:
ahh ok.
yeah it would be nice that that is configurable somehow (maybe per engine/script implementation or something)

But then that fix i did yesterday was really needed.

johan



On Thu, Jul 10, 2008 at 3:14 PM, Alexey Panchenko <alex@xxxxxxxxx> wrote:
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
>

_______________________________________________
dltk-dev mailing list
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




--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



Back to the top