Our wrapping optimization relied on the caller context having a TRY block,
but each context (including internal calls!) has an exception handling stack
of its own, which means that for an invocation stack of
entry
A.someMethodFromEntry() # this one has a TRY
A.internalMethodViaCALL() # this one doesn't
B.someMethod()
we get `HasTryBlock() == false` for `A.internalMethodViaCALL()` context, which
leads to missing wrapper and missing rollbacks if B is to THROW. What this
patch does instead is it checks for any context within contract boundaries.
Fixes#3045.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We don't use all of the Stack functionality for it, so drop useless methods
and avoid some interface conversions. It increases single-node TPS by about
0.9%, so nothing really important there, but not a bad change either. Maybe it
can be reworked again with generics though.
v.estack is used throughout the code to work with estack, while ctx.sc.estack
is (theoretically) just a reference to it that is saved on script load and
restored to v.estack on context unload. The problem is that v.estack can grow
as we use it and can be reallocated away from its original slice (saved in the
ctx.sc.estack), so either ctx.sc.estack should be a pointer or we need to
ensure that it's correct when loading a new script. The second approach is a
bit safer for now and it fixes#2798.
Share parameters parsing code between 'contract invokefunction' and
'vm run' commands. It allows VM CLI to parse more complicated parameter
types including arrays and file-backed bytestrings.
Adding an array multiple times leads to the fast update via `IncRC`.
This hides the allocation that is there on the first addition. In this
commit add another benchmark which measures Add/Remove together, to
ensure that `switch` in `refCounter.Add` is entered. Benchmark results
are meaningful, because `Add`/`Remove` have almost identical implementation.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
And determine the need for Null dynamically. For some reason the only dynamic
context is Contract.Call. CALLT is not dynamic and neither is a call from
native contract, go figure...
We use it a lot in (*Blockchain).IsTxStillRelevant().
name old time/op new time/op delta
IsSignatureContract-8 19.1ns ± 5% 1.2ns ± 4% -93.81% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
IsSignatureContract-8 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
IsSignatureContract-8 0.00 0.00 ~ (all equal)
Perform add/set/remove operations with VM type firstly, and with
refcounter after that. It is needed to be able to extend add/set/remove
operations with extra checks.
