Re: Re: LocalVariableSorter

  Usually that happen when you are making direct calls to the next
visitor in chain instead of using super.visit*() calls. But if that is
not the case, try to reproduce this issue in a small isolated test, so
we can look at it.

  regards,
  Eugene


On Wed, Sep 15, 2010 at 1:57 PM, Nikolas Nehmer
<[email protected]> wrote:
> Hi Eugene,
>
> in fact, I don't need the variable to be in the localVar table. But as
> mentioned in my first mail, just using the newLocal method provided by the
> localVarSorter doesn't work. Obviously the Sorter is doing "something" (i.e.
> it seems to be invoked in the right way )- e.g. shifting the indexPositions
> of exisitng variables in the table - leaving "space" for the created
> variable. But if I try to access the new variable with a store operation,
> the store operation's index in the bytecode changes automatically to a value
> that is defined in the variable table (in contrast to the new variable that
> is not defined in the table).
> ISTORE 1 automatically changes to ISTORE 0 e.g. when looking at bytecode
> after the instrumentation process using a TraceClassVisitor. Of course this
> usually ends in a verify error because of typing problems. So basically my
> problem is not to insert new entries to the table, but to prevent the
> bytecode to change by some magic. It seems as if the index in the store
> operation is changing because "something" decided that at this point in time
> no variable could be accessed at the given index position. Any
> recommendations to solve that problem?
>
> Eugene Kuleshov schrieb:
>>
>> Nikolas,
>>
>>  If you need your new variable in the local var table debug info,
>> then you should call visitLocalVariable() method
>>
>>  regards,
>>  Eugene
>>
>>
>> On Wed, Sep 15, 2010 at 12:26 PM, Nikolas Nehmer
>> <[email protected]> wrote:
>>
>>>
>>> Hi,
>>>
>>> I have a question regarding the LocalVariableSorter. I`m trying to add an
>>> additional local variable calling the newLocal method. Looking at the
>>> localVariable entries in the resulting bytecode, one can see that the
>>> variable indexes are "shifted" according to the added variable - but
>>> there
>>> is no additional entry added to the localVariable table. If I'm trying to
>>> access the added variable at the corresponding index position, the index
>>> within the store (let's asume it's a store statement that I'm using to
>>> access the newly defined variable) statement is shifted (by some magic)
>>> to a
>>> close value that is present (index 1 --> index 2) in the local variable
>>> table. Any ideas?
>>>
>>> Best regards
>>> Nikolas
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the [email protected] mailing list.
>>> To unsubscribe: mailto:[email protected]
>>> For general help: mailto:[email protected]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>
>>>
>>>
>
>
> --
> Dipl.-Inf. Nikolas Nehmer,
> Dept. of Computer Science. University of Kaiserslautern P.O. Box 3049, 67653
> Kaiserslautern, Germany.
> room 36/308, phone: +49 (0) 631 - 205 2644, fax: +49 (0) 631 - 205 3299
> mail: [email protected]
>
>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws