A Как я уже говорил в предыдущих комментариях, я думаю, что это ошибка компилятора, основанная на том простом факте, что компилятор выдал недопустимый байт-код, и игрок смог перехватить этот искаженный байт-код и выдать VerifyError соответственно.
Однако после некоторого расследования я обнаружил пару интересных вещей.
Во-первых, выводы Джуни поставили меня на правильный путь. Очевидно, как показывает его код, вы можете заставить компилятор перевести то, что находится в квадратных скобках, как доступ к свойству.
Итак, это:
foo[foo,'length']
эквивалентно:
foo["length"]
Здесь есть проблема, но я объясню через секунду.
Вы также можете вызывать методы, например так:
var foo:Array = [];
foo[foo,'push'](1);
trace(foo);
Это эффективно подтолкнет 1 в foo
С некоторыми дополнительными хитростями, вы можете связать все это, чтобы получить этого мерзкого зверя:
var inner:Array = [10];
var outter:Array = [1,2,inner];
(inner[outter, 'pop']).call(null)[inner,'push'].call(null,20);
trace(inner);
trace(outter);
Это эквивалентно:
var inner:Array = [10];
var outter:Array = [1,2,inner];
outter.pop().push(20);
То есть мы извлекаем inner из outter и затем нажимаем 20.
Я начал замечать, что здесь
inner[outter, 'pop']
inner не используется.
На самом деле вы можете изменить его на:
null[outter,'pop']
или даже
(void)[outter,'pop']
И компилятор не будет жаловаться на это (и проигрыватель не будет). Я сомневаюсь, что вышеприведенный синтаксически действительный Actionscript (в этом случае компилятор должен отказаться от его компиляции), но я не уверен на 100%. Однако этот неиспользуемый объект является корнем проблемы. (Следующее требует некоторых базовых знаний о том, как работает флеш-сборка или любая другая сборка на основе стека, но я надеюсь, что смогу объяснить это так, чтобы ее можно было понять, не предполагая слишком много.)
Я разобрал байт-код, сгенерированный этим кодом ActionScript:
var arr:Array = [10];
null[arr,'length'];
Разобранный код:
function private::initLevel():void /* disp_id 0*/
{
// local_count=2 max_scope=1 max_stack=3 code_len=17
0 getlocal0
1 pushscope
2 pushbyte 10
4 newarray [1]
6 coerce Array
8 setlocal1
9 pushnull
10 getlocal1
11 pushstring "length"
13 getproperty null
15 pop
16 returnvoid
}
Пойдемте шаг за шагом. instr - смещение инструкции; stack_state показывает текущее состояние стека после выполнения инструкции; comments говорит само за себя;)
instr stack_state comments
-------------------------------------------------------------------------------------------
0 this "this" is always passed in local register 0 to instance methods
1 "this" is added to the scope chain and popped
2 10 now, we have 10 on the stack
4 [10] an array is created and initialized taking 1 element from the stack
6 [10] this is sort of like doing [10] as Array
8 the array is assigned to local variable 1
9 null null is pushed. That is the null in this line:
null[arr,'length']
HERE BEGINS THE PROBLEM!
10 null,local1 local 1 is pushed
11 null,local1,"length" the string constant "length" is pushed
13 null,local1["length"] getproperty null is used for dynamic lookup (object["prop"]). Both operands are popped from the stack
15 null in the previous step, the result of local1["lengtht"] was pushed. But we dind't use it, so it's discarded
16 null here the method returns. The stack should be empty, but it's not.
The generated code should have popped the null pushed at #9,
or it shouldn't have pushed it in the first place
Проблема в том, что после выхода из метода все объекты, помещенные в стек методом, должны были вытолкнуться. Это не так, так как константа null остается в стеке после возврата метода. Другими словами, у нас есть несбалансированный стек . Теперь игрок явно не против или не проверяет. Я думаю, что он должен и не должен запускать этот код, так как это может (по крайней мере, потенциально) привести к переполнению стека, если он вырастет достаточно большим.
Теперь, если мы изменим секцию проблемного кода, которая будет включена в блок перехода (например, блок, достигнутый после условного перехода, такого как if), игрок отклоняет код с сообщением:
VerifyError: Error #1030: Stack depth is unbalanced. 1 != 0.
Так же, как ОП. Таким образом, кажется, что наличие ветви запускает какую-то проверку целостности стека в плеере. На этом этапе следует отметить, что цикл Actionscript (любой вид цикла) реализован на уровне байт-кода в виде условного перехода, как ìf. Поэтому, хотя у нас нет цикла в следующем коде (if создает код, который короче и проще для анализа), так как он запускает эту проверку в проигрывателе, для наших целей он аналогичен цикл, как сделал ОП.
В коде AS:
var dummy:int = 1;
var arr:Array = [10];
if(dummy != 0) {
null[arr,'length'];
}
Разобранный:
function private::initLevel():void /* disp_id 0*/
{
// local_count=3 max_scope=1 max_stack=3 code_len=27
0 getlocal0
1 pushscope
2 pushbyte 1
4 setlocal1
5 pushbyte 10
7 newarray [1]
9 coerce Array
11 setlocal2
12 getlocal1
13 pushbyte 0
15 ifeq L1
19 pushnull
20 getlocal2
21 pushstring "length"
23 getproperty null
25 pop
L1:
26 returnvoid
}
Шаг за шагом:
instr stack_state comments
-------------------------------------------------------------------------------------------
0 this "this" is always passed in local register 0 to instance methods
1 "this" is added to the scope chain and popped
2 1 now, we have 1 on the stack
4 1 is popped and assigned to the local variable 1 (the dummy var in the code)
5 10 10 is pushed
7 [10] an array is created and initialized taking 1 element from the stack
9 [10] this is sort of like doing [10] as Array
11 the array is assigned to local variable 2 (the arr var in the code)
12 local1 local1 (dummy) is pushed
13 local1,0 0 is pushed
15 this instruction consumes (pops) both local1 and 0 to compare them
If this condition is satisfied, it jumps to the label L1
If it is not, it falls-through to the next instruction
(the same as a case label in a switch statement that does not have a break, in Actionscript code)
19 null null is pushed. That is the null in this line:
null[arr,'length']
Again, HERE BEGINS THE PROBLEM!
20 null,local2 local2 is pushed
21 null,local2,"length" the string constant "length" is pushed
23 null,local2["length"] getproperty null is used for dynamic lookup (object["prop"]). Both operands are popped from the stack
25 null the value returned by local2["length"] is discarded
26 null the method returns, but null is not properly popped from the stack!
Итак, снова, null все еще находится в стеке после возврата метода; стек несбалансированный . Но на этот раз игрок проверяет это, находит проблему, выдает VerifyError и прерывает код.
В любом случае, чтобы подвести итог, я пришел к выводу: компилятор генерирует недопустимый байт-код в обоих случаях. Я думаю, что это ошибка. Игрок отклоняет этот код, если он может его обнаружить. Но, похоже, он сможет обнаружить его только в том случае, если проблемный код находится внутри блока перехода (тоже похоже на ошибку).
Добавление:
Джойни упоминает в комментарии, что «Если вы вернетесь непосредственно перед прыжком, то без ошибок».Что является правдой.Причина в том, что код внутри if, но после возврата является «мертвым кодом», поэтому компилятор удаляет его из байт-кода.
Таким образом, не сам переход заставляет проигрыватель проверять целостность стека,Я немного погуглил и нашел это на сайте haxe .
Это несбалансированная ошибка стека.Это означает, что две ветви перехода приводят к разным размерам стека, когда они присоединяются обратно.Все переходы или код, ведущий к данной позиции, должны приводить к одному и тому же размеру стека.
Что делает все это более понятным.
Во втором примере кода выше, это то, что на самом делепроисходит.
Если код следует за переходом по инструкции 15, он попадает непосредственно в последнюю инструкцию (26), чтобы вернуться к вызывающей стороне.null не был передан, и в стеке больше ничего нет, поэтому мы приходим к этому моменту с размером стека 0.
Если код не перепрыгивает и проваливается, null будетбыть вытолкнутым (19) и не оторваться.Таким образом, этот путь достигнет последней инструкции (26) с null в стеке, что означает, что размер стека равен 1. Эта последняя инструкция является точкой, где обе ветви соединяются назад, но после одной ветви размер стека равен 0, следуя за другим, это 1. И это то, что заставляет игрока жаловаться на несбалансированный стек.