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.
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...
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.
We can omit DAO wrapping for safe methods and for those methods that are not
wrapped into try-catch block. However, we still need to persist
notificationsCount changes for these methods to the parent context.
As can be seen in https://dotnetfiddle.net/s7eg21 (int) conversions
result in an exception in C# code.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
When there is a single big instruction (like PUSHDATA4) in script,
all other instructions are padded to the right with spaces.
This makes it hard to view script in terminal, because long lines
are usually wrapped at the screen boundary and printed as multiple lines.
The culprit is our `cursor` field which is printed in the last column
and causes all previous fields to have the same length for every
instruction. One way to fix this is to omit cursor field if it is empty.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
vm.New() creates a new stack, then we load an entry script with
LoadScriptWithFlags and it creates another one which doesn't make much
sense. rvcount is -1 for it, so all elements are to be copied down anyway and
it's clear so a new loaded script can't dig down to anything it shouldn't be
able to.
