Справочная и точная ссылка в Dalvik Verifier

Если вы внимательно посмотрите на ошибку, она говорит вам, что вы передаете Object вместо ожидаемого String. В любом случае, больше ничего нельзя сказать, если вы не опубликуете фактический байт-код, который вызывает проблему.

Вы уверены, что 0x570 указывает на середину инструкции? Это не должно. В любом случае, способ отладки - это посмотреть на соответствующую инструкцию и выяснить, почему r5 является объектом, когда он должен быть строкой. Или вы можете опубликовать байт-код, чтобы я мог посмотреть.

Изменить: теперь, когда вы разместили код, на самом деле есть путь, который приводит к тому, что v5 является объектом, но это немного тонко

Обработчик исключений .catch JSONException {:5D8 .. :938} :BDE переходит к :BDE

Код обработчика исключений сохраняет перехваченное исключение в v5, что означает, что v5 больше не является строкой на данный момент. Затем он переходит к :162

:BDE
00000BDE  move-exception      v5
00000BE0  const               v0, 0x00488B36
00000BE6  invoke-static       Logger->logBasicBlockEntry(I)V, v0
00000BEC  goto/16             :162

:162 находится в пределах диапазона другого обработчика исключений: .catch ClassNotFoundException {:2E .. :594} :BF0

:Bf0 оставляет v5 нетронутым и переходит к :A28

:BF0
00000BF0  move-exception      v6
00000BF2  const               v0, 0x00488B3E
00000BF8  invoke-static       Logger->logBasicBlockEntry(I)V, v0
00000BFE  goto/16             :A28

:A28 — это начало блока кода, который предполагает, что v5 — это String. В частности, в инструкции :AE0 v5 передается функции, принимающей строку.

00000AE0  invoke-virtual      StringBuilder->append(String)StringBuilder, v7, v5

0xAE0 ровно в два раза больше 0x570, что объясняет смещение, показанное в ошибке, после того, как вы настроите единицы кода, как предложил JesusFreke.

Обратите внимание, что это не обязательно единственный неработающий путь кода, это просто первый, который я нашел, просматривая ваш код. Однако одного неверного пути достаточно, чтобы унифицировать тип v5 с JSONException и, следовательно, превратить его в Object.

0x570, вероятно, является смещением в единицах кода, каждая из которых составляет два байта. Таким образом, смещение байта на самом деле равно 0xAE0, что соответствует инструкции, и эта инструкция ссылается на v5.

Я ожидаю, что происходит то, что где-то есть код, который хранит строку в v5, но есть еще один путь кода, который сливается между тем, где строка хранится в v5, и где она используется, и этот путь кода имеет другой тип объекта, хранящийся в v5 . Когда пути кода сливаются, он использует общий суперкласс двух типов в качестве типа регистра. Поэтому, если эти два типа совершенно не связаны, java.lang.Object будет суперклассом.

Чтобы отладить эту проблему, вы можете запустить baksmali с параметром --register-info ARGS,DEST,FULLMERGE (а также --code-offsets, чтобы вы могли легко найти 0xAE0), а затем просмотреть 0xAE0 назад и посмотреть, где тип v5 установлен как объект.

Я хотел бы добавить свой ответ, так как другие были очень полезны, пожертвовав своим временем, чтобы ответить на сложный вопрос, который, вероятно, мало что обобщает!

Как указывает @Antimony, в моем коде был путь управления, который начинался с обработчика исключений, сохранял исключение в v5 (в результате чего v5 было Object), а затем goto'da указывал внутри исключения обработчик. Затем этот обработчик исключений вызвал использование v5 в качестве строки, что вызвало ошибку верификатора.

В исходном коде приложения единственной тонкой целью этого goto была инструкция return-void. Из-за этого верификатор Dalvik не распространял путь к обработчику исключений.

К сожалению, когда я переписал это приложение, это привело к тому, что цель этого обработчика исключений содержала больше, чем просто эту инструкцию return-void, делая причину проверки через этот блок и в перехваченный обработчик исключений. В частности, перед return-void я вставил вызов Logger.logMethodExit, который затем предполагает, что верификатор может передать управление обратно обработчику исключений (в данном случае :BF0) и, в конечном счете, в то место, где v5 использовалось как строка. В исходном приложении он был убит (в смысле потока данных gen/kill). Но при переписывании я включил этот дополнительный вызов, нарушающий инварианты потока данных... Грязь.

Я думаю, что знаю, как исправить это в моей реализации, но понять это было очень сложно!

Более общие уроки, извлеченные здесь:

• Смещения ошибок верификатора на самом деле просто 2 * индекс в байт-коде

• В отличие от байт-кода JVM, байт-код Dalvik считает подмножество кодов операций невыбрасываемыми, включая return. Это повлияет на анализ потока данных

• Точная ссылка означает, что что-то ограничено определенным уточнением объекта в одном базовом блоке и Object в другом (хотя эта ошибка кажется мне немного эзотерической..)

• Когда вы переписываете байт-код, вам нужно знать о наборах gen/kill, с которыми вы неявно работаете, и, в частности, инструкции return-* немедленно уничтожат все, в то время как переход к началу базового блока внутри try.. продолжит сохранять эти вещи живут.