IPhone SDK 3.0 и symbolicatecrash не ладят?

Ответ 1

Предложения Грега, не работали для меня, но помогли указать правильное направление для получения журналов plcrashreporter (репортер версии 103), чтобы снова символизировать sdk 4.0.

BTW: это проблема, с которой вы обязательно столкнетесь с отчетами, созданными на более новых устройствах (armv7) потому что символ предполагает, что сообщения версии 103 являются armv6.

Так вот что я сделал...

1)

создайте копию из новейшего символа crash script (sdk 4.0) для внесенных изменений. Примечание: в зависимости от использования редактора вы можете установить исполняемый бит после редактирования. chmod 755 symbolicatecrash

2) проблема: поиск символов - NO MATCH

это потому, что по умолчанию установлено значение armv6.

Разрешение: в sub parse_images установить архитектуру по умолчанию my $default_arch = 'armv7';

3) выпуск: "Использование неинициализированного значения $bundle..."

Разрешение: (hack: удаление некоторых ограничений, которые, похоже, не работают в 103 отчетах)

заменить:

$app = $bundlename if (!defined $app && defined $image{plus} && length $image{plus});

по:

$app = $bundlename if (!defined $app);

4) проблема: "невозможно понять вывод из otool"

Разрешение: Грег исправить для sub matchesUUID.

заменить:

} else { die "Can't understand the output from otool ($TEST_uuid)"; }

по:

} else { if ($arch eq "armv7") { return matchesUUID($path, $uuid, "armv6"); } else { die "Can't understand the output from otool ($TEST_uuid)"; } }

5): "atos не может найти символы"

здесь изменения Gregs script не работают,

• кажется, что <$ph> в rindex( потеряно в подсветке кода.
• "atos не может загружать символы" не был передан в script - поэтому проверка не будет работать
• <$ph> in rindex( check считывает первую строку... так что один кадр теряется, если он был успешным. В качестве "взлома" я просто подделал рамку с adreass 1... которая "используется" во время проверки atos.

Итак, это то, что я изменил в sub symbolize_frames:

заменить:

my $cmd = "$atos -arch $arch -o '$escapedSymbol' @{[ keys %$frames ]} | ";

по:

my $cmd = "$atos -arch $arch -o '$escapedSymbol' 1 @{[ keys %$frames ]}  2>&1 | ";

заменить:

open my($ph),$cmd or die $!;

по:

open my($ph),$cmd or die $!;
if (rindex(<$ph>, "atos cannot load symbols") != -1 && $arch eq "armv7") {
    my $arch = "armv6"; my $cmd = "$atos -arch $arch -o '$escapedSymbol' @{[ keys %$frames ]}  2>&1 | ";
    print STDERR "Running $cmd\n" if $opt{v};
    open $ph,$cmd or die $!;
}

Примечание: при этом изменения script выполняются отлично для меня - "исправления", вероятно, не очень элегантные, но я не уверен в Perl:)...

Ответ 2

Если вы столкнулись с ситуацией, когда при запуске символьного сбоя символизируются только ваши собственные библиотеки, но системные библиотеки не символизируются, а у вас есть 3.0+ iPhone SDK, скорее всего, проблема заключается в том, что формат отчета, который вы Символизм - более старый формат. Одним из полей заголовка в отчете о сбое является "Версия отчета", это версия отчета о сбоях. Самая последняя версия (на момент написания iPhone OS 3.2.1) - "104". Тем не менее, symbolicatecrash обрабатывает версии 102 и 103. Версия 104 представила новую новую архитектуру чипа (armv7), а бинарные изображения имеют возможность указывать используемую архитектуру чипа. В версиях 102 и 103 отчета о сбое не указывается используемая архитектура микросхемы. Самая последняя версия symbolicatecrash предполагает использование armv6 для версий 102 и 103 отчета. Вероятно, это неверно.

Символьная авария должна быть написана для большей совместимости со старыми форматами отчетов. В общем, UUID для двоичных изображений - это все, что вам нужно, чтобы правильно сопоставить символы системной библиотеки для правильной версии ОС, а также архитектуры - архитектура, вероятно, избыточна. Однако для того, чтобы это произошло правильно, необходимо изменить символический сбой script, чтобы в дополнение к итерированию всех версий системной библиотеки, установленных на главной машине, чтобы найти нужную библиотеку, также необходимо выполнить итерацию все архитектуры чипов. Это, к счастью, довольно легко изменить.

Чтобы справиться с этим, я сделал следующие изменения:

в подпрограмме getSymbolPathFor:

if ( defined($temp_path) && matchesUUID($temp_path, $uuid, $arch) ) {
                        $out_path = $temp_path;
                        @out_path_arr = {};
                    } else {
                        undef $temp_path;
                        print STDERR "-- NO MATCH\n"  if $opt{v};
                    }

измените на:

if ( defined($temp_path) && matchesUUID($temp_path, $uuid, $arch) ) {
                        $out_path = $temp_path;
                        @out_path_arr = {};
                    } else {
                        if ( defined($temp_path) && matchesUUID($temp_path, $uuid, 'armv7') ) {
                            $out_path = $temp_path;
                            @out_path_arr = {};
                        } else {
                            undef $temp_path;
                            print STDERR "-- NO MATCH\n"  if $opt{v};
                        }
                    }

Это проверит различные архитектуры чипов UUID на хост-системе, чтобы найти совпадение с UUID в разделе двоичного изображения в отчете о сбое (и если предстоящий iPhone 2010 имеет другую архитектуру микросхемы, которая должна быть добавлена ​​к этому, если -ее условие).

Для следующего изменения фрагмент кода поиска UUID является хрупким. Если otool не возвращает то, что может распознать symbolicatecrash, symbolicatecrash выйдет. В случае, когда вы тестируете UUID архитектуры, которая не распознается хост-машиной, otool ничего не вернет, а символика crash умирает. Вам нужно сделать символический сбой немного более мягким, просто проигнорируйте результат otool, чтобы он мог перейти к следующей архитектуре, которую вы проверяете.

Измените подпрограмму matchUUID:

if ( $test eq $uuid ) {
        ## See that it isn't stripped.  Even fully stripped apps have one symbol, so ensure that there is more than one.
        my ($nlocalsym) = $TEST_uuid =~ /nlocalsym\s+([0-9A-Fa-f]+)/;
        my ($nextdefsym) = $TEST_uuid =~ /nextdefsym\s+([0-9A-Fa-f]+)/;
        my $totalsym = $nextdefsym + $nlocalsym;
        print STDERR "\nNumber of symbols in $path: $nextdefsym + $nlocalsym = $totalsym\n" if $opt{v};
        return 1 if ( $totalsym > 1 );

        print STDERR "## $path appears to be stripped, skipping.\n" if $opt{v};
    } else {
                    print STDERR "Given UUID $uuid for '$path' is really UUID $test\n" if $opt{v};
            }
} else {
            die "Can't understand the output from otool ($TEST_uuid)";
    }

Для чего-то более снисходительного:

if ( $test eq $uuid ) {
        ## See that it isn't stripped.  Even fully stripped apps have one symbol, so ensure that there is more than one.
        my ($nlocalsym) = $TEST_uuid =~ /nlocalsym\s+([0-9A-Fa-f]+)/;
        my ($nextdefsym) = $TEST_uuid =~ /nextdefsym\s+([0-9A-Fa-f]+)/;
        my $totalsym = $nextdefsym + $nlocalsym;
        print STDERR "\nNumber of symbols in $path: $nextdefsym + $nlocalsym = $totalsym\n" if $opt{v};
        return 1 if ( $totalsym > 1 );

        print STDERR "## $path appears to be stripped, skipping.\n" if $opt{v};
    } else {
                    print STDERR "Given UUID $uuid for '$path' is really UUID $test\n" if $opt{v};
            }
} else {
            #die "Can't understand the output from otool ($TEST_uuid)";
            print "Can't understand the output from otool ($TEST_uuid)";
    }

После того, как я сделал эти изменения, я смог увидеть, что системные объекты получают символически правильно (а также мой собственный код), когда я использую отчеты об ошибках 102 и 103 с текущим iPhone SDK (3.1.2).

Ответ 3

Я испытал ту же самую проблему и смог ее исправить, изменив символический crash script. Проблема для меня заключалась в том, что как "otool", "atos", так и "size" не очень хорошо сочетались с модулями, скомпилированными для armv7. Существуют версии этих инструментов, которые хорошо работают с такими модулями, которые можно найти в /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin. Для otool символика crash script, найденная в /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources, уже использует механизм для поиска соответствующей версии:

# Find otool from the latest iphoneos
my $otool = `xcrun -sdk iphoneos -find otool`;
chomp($otool);
my $atos = `xcrun -sdk iphoneos -find atos`;
chomp($atos);

Однако "размер" используется напрямую:

if (-e '/usr/bin/size') {
    open my($ph),"-|",'size','-m','-l','-x',$symbol or die $!;

Изменение этого фрагмента кода к уродливому:

if (-e '/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/size') {
    open my($ph),"-|",'/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/size','-m','-l','-x',$symbol or die $!;

похоже, заставляет его работать.

Ответ 4

Я знаю, что для SDK 3.0 они переместили symbolicatecrash в новое место, и мне пришлось получить эту новую версию, чтобы снова отобразить сопоставления символов.

Для 3.0 он находится по адресу: /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources

Так что, возможно, стоит убедиться, что у вас самая последняя версия. Я вижу правильное отображение символов для моих исходных и API-функций.

Ответ 5

Я испытывал точно такую ​​же проблему - отображались символы для системных модулей, но не из моего приложения. Оказывается, это потому, что мои .dSym файлы не могли быть найдены прожектором, поскольку я "скрывал" все продукты сборки, указав в настройках, что все файлы сборки входят в каталог ".xcode-build". Изменение этого параметра на "xcode-build" устранило проблему!

Ответ 6

одно, чтобы проверить. если вы знаете файл dsym, с которым хотите сопоставить, затем щелкните правой кнопкой мыши на файле dsym и выберите "Получить информацию". В разделе дополнительной информации содержится UUID для файла dsym. Для того, чтобы символика работала, UUID для вашего приложения (заключенный в угловые скобки в разделе двоичных изображений журнала сбоев), должен соответствовать UUID файла DSYM.

Я нашел проблему в моем использовании PLCrashReporter, где UUID в журнале сбоев не соответствовал UUID сгенерированного файла dsym, что привело к сбою символа.

Ответ 7

Изменить символическую краху. Перейдите к строке 506 и измените это:

    ARM      =>  "armv6",

:

    ARM      =>  "armv7",

Ответ 8

У меня было множество runins с символикой crash, последняя с момента обновления до SDK 4. Несмотря на то, что я построил архитектуру armv6 и amrv7, otool и atos задушили бинарное изображение приложения. Я сделал следующие изменения, и все работает снова. Надеюсь, это поможет.

FROM (sub symbolize_frames):

open my($ph),$cmd or die $!;

TO:

open my($ph),$cmd or die $!; if (rindex(, "atos cannot load symbols" != -1 && $arch eq "armv7")) { $arch = "armv6"; my $cmd = "$atos -arch $arch -o '$escapedSymbol' @{[ keys %$frames ]} | ";

print STDERR "Running $cmd\n" if $opt{v};
open $ph,$cmd or die $!;

}код >

и

FROM (sub matchesUUID):

} else { die "Can't understand the output from otool ($TEST_uuid)"; }

TO:

} else { if ($arch eq "armv7") { return matchesUUID($path, $uuid, "armv6"); } else { die "Can't understand the output from otool ($TEST_uuid)"; } }