Программа переполняет стек вызовов только силой воли

Question

Вот стек вызовов из отчета о сбое пользователя :

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.growl.GrowlSafari           0x179d383c writeWithFormat + 25
1   com.growl.GrowlSafari           0x179d388e writeWithFormat + 107
2   com.growl.GrowlSafari           0x179d388e writeWithFormat + 107
3   com.growl.GrowlSafari           0x179d388e writeWithFormat + 107
4   com.growl.GrowlSafari           0x179d388e writeWithFormat + 107
5   com.growl.GrowlSafari           0x179d388e writeWithFormat + 107

Трассировка обрезается в кадре 511.

Вот writeWithFormat:

int writeWithFormat(FILE *file, NSString *format, ...) {
    va_list args;
    va_start(args, format);
    int written = writeWithFormatAndArgs(file, format, args);
    va_end(args);
    return written;
}

Как видите, он не вызывает сам себя.

Вот функция, которую он вызывает:

int writeWithFormatAndArgs(FILE *file, NSString *format, va_list args) {
    return 0;
    return fprintf(file, "%s\n", [[[[NSString alloc] initWithFormat:format arguments:args] autorelease] UTF8String]);
}

(Как вы можете догадаться, это код регистрацииэто деактивировано.)

Итак, как этот код приводит к трассировке стека?

---

Разборка с использованием otx:

_writeWithFormatAndArgs:
    +0  00000f68  55                    pushl       %ebp
    +1  00000f69  89e5                  movl        %esp,%ebp
    +3  00000f6b  31c0                  xorl        %eax,%eax
    +5  00000f6d  c9                    leave
    +6  00000f6e  c3                    ret

_writeWithFormat:
    +0  00001823  55                    pushl       %ebp
    +1  00001824  89e5                  movl        %esp,%ebp
    +3  00001826  83ec10                subl        $0x10,%esp
    +6  00001829  31c0                  xorl        %eax,%eax
    +8  0000182b  c9                    leave
    +9  0000182c  c3                    ret

Answer 1

В полном отчете о сбое вы можете увидеть в разделе бинарных файлов, что у пользователя есть две загруженные копии GrowlSafari:

 0x140c000 -  0x140efff +com.growl.GrowlSafari 1.1.6 (1.1.6) <1E774BDF-5CC5-4876-7C66-380EBFEAF190> /Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/PlugIns/GrowlSafari.bundle/Contents/MacOS/GrowlSafari
0x179d2000 - 0x179d4ff7 +com.growl.GrowlSafari 1.2.1 (1.2.1) <10F1EF69-D655-CCEE-DF3A-1F6C0CF541D3> /Applications/GrowlSafari.app/Contents/Resources/GrowlSafari.bundle/Contents/MacOS/GrowlSafari

Код, который я показал в вопросе, взят из 1.2.1 (но есть большая вероятность, что он не изменился с 1.1.6), а разборка - 1.2.1.

Вероятно, это и является причиной проблемы, особенно потому, что рекурсия, похоже, на самом деле выполняется быстрым способом (спасибо @_karsten_ в Твиттере за , указывающую на это ).

Answer 2

Конечный вызов где-то там может вызывать исчезновение одной или нескольких функций из трассировки стека, что, конечно, делает отладку очень увлекательной.

Вдобавок ко всему, я мог бы подумать о двух возможных сценариях, которые могли бы вызвать это:

• строка формата является подклассом NSString, или где-то есть категория, которая вызывает вызов writeWithFormat () во время этой writeWithFormat (). Настраиваемый код записи в журнал иногда делает это - пугающе легко написать какой-то общий код регистрации, который с радостью перезвонит сам себе. Был там, сделал это. Много раз, к сожалению.

• извращение в памяти вызывает рекурсию; поврежденный объект или что-то.

Оба немного разбираются в соломе. Разместите полный отчет о сбое.

<Ч />

Две версии комплекта, изобилующего средой выполнения ... все ставки отключены, пока сбой не будет воспроизведен только в случае одного из этих комплектов. Могу поспорить, что это проблема.

Могу поспорить, что есть какое-то смежное консольное выпадение.