Обнаружение исключения из трассировки стека выпуска - PullRequest
Новая
       18

Обнаружение исключения из трассировки стека выпуска

1 голос
/ 29 марта 2019

У меня есть приложение Xamarin для Android, которое периодически развертывается на тестерах.Я записываю трассировку стека, когда приложение имеет необработанное исключение, однако мне трудно определить источник сбоя трассировки.Я нашел эту статью о получении имен файлов / номеров строк в трассировках стека сборки выпуска и реализовал ее в своем коде (https://developer.xamarin.com/releases/android/xamarin.android_6/xamarin.android_6.1/#Release_Stack_Traces). Примечание. Мне действительно пришлось изменить параметр отладочной информации на «Полный», чтобы процесс сборки генерировалКаталог msym.

Я проверил эту функциональность, добавив в свое приложение кнопку, которая вызывает необработанное исключение. Как и ожидалось, я смог использовать утилиту mono-symbolicate, чтобы определить источник исключения из отслеживаемой трассировки стека..

Я заметил, что содержимое папки msym названо случайным образом, поэтому после перестройки приложения я развернул новую сборку и сохранил ее из каталога msym. Ниже приведена трассировка стека, полученная из отчета о сбое. 

Object reference not set to an instance of an object

 at MyApp.Droid.Dashboard.DashboardActivity+<OnResume>d__18.MoveNext () [0x0003b] in <e3858b3570dd4244985ab7c8da45615a>:0 \n--- End of stack trace from previous location where exception was thrown ---\n 
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <151302d8db184dfd9dfbf4e0ac550df9>:0 \n 
 at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_0 (System.Object state) [0x00000] in <151302d8db184dfd9dfbf4e0ac550df9>:0 \n 
 at Android.App.SyncContext+<>c__DisplayClass2_0.<Post>b__0 () [0x00000] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00008] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at (wrapper dynamic-method) System.Object.452a73e4-d2f9-4ade-a6c1-b8346138dd0d(intptr,intptr)","reportType":"UHELogEntry","timestamp_ticks":636894071182040326}

Однако, когда я запускаю утилиту моносимвольных символов на приведенной выше трассировке, утилита жалуется следующим предупреждением: 

    Warning: MVID directory does not exist: .\e3858b3570dd4244985ab7c8da45615a

Легко видеть, что исключение исходит от OnResume.метод DashboardActivity (см. ниже). Но естьСуществует несколько возможных источников исключения, но ни один из них не представляется вероятным, поэтому я хотел бы иметь лучшее представление о том, откуда происходит исключение, прежде чем я пойду в погоню за диким гусем.

protected override async void OnResume()
{
    base.OnResume();
    var provider = KernelBuilder.KERNEL.Get<ServiceProvider>();
    await provider.initializationTask;

    _service = provider.getService();
    Log.Debug(TAG, string.Format("OnResume, post service assignment", "Service: " + (_service?.ToString() ?? "null")));

    var wrapper = new ExerciseServiceWrapper(_service, null);
    _connectionView.Setup(wrapper, _service.userSetupHardware);

    _service?.stopRecordingSession();
    LibITagAndroid.ContinuousITagClickSrc.instance.stop();
}

У меня следующие вопросы:

  1. Почему моносимвольный инструмент не может преобразовать трассировки стека в номер файла / строки?
  2. Можно ли использовать информацию, закодированную в имени метода в верхней части трассировки стека (MyApp.Droid.Dashboard.DashboardActivity + d__18.MoveNext), чтобы сузить источник возникновения исключения?Похоже, что суффикс d__18 может указывать, произошло ли исключение до или после вызова await provider.initializationTask, но я не нашел ничего, что помогло бы мне понять этот суффикс.

Дополнительное наблюдение:

Я заметил, что если я установлю отладочную информацию на «Полный» и отключу «Оптимизировать код», я получу путь к файлу / номера строк, сообщенные в трассировке стекамоих тестовых исключений, но не исключений, возникающих в функции OnResume.Это заставляет меня думать, что это происходит где-то «особенным», может быть, обеспечиваетсяr.initializationTask пусто?

Спасибо!

Джон

...