iPhone: общие советы по отладке

Question

Я занимался разработкой для iPhone 8 месяцев или около того, и жизнь в целом хорошая (исключение составляет openGL lol).

Я создавал игру для iPhone 3D, и все шло хорошо. Он отлично работает на симуляторе (я не знаю, настоящий тест), и он работал нормально на устройстве.

Теперь кажется, что он умирает на устройстве и указывает на некоторые очень случайные вещи. Первый раз, когда он умирает («EXC_BAD_ACCESS»), это настройка делегата.

NSString *url = [NSString
stringWithFormat:@"%@GetPlayerPosition.aspx?playerIndex=%@",
self.baseURL, self.deviceID];
__block ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:[NSURL URLWithString:url]];    
[request setDelegate:self];

Так что я просто удаляю код.

В следующий раз, когда он умрет, он попытается получить доступ к массиву GLFloat

GLfloat v [] = {центр [0] - глаз [0], центр [1] - глаз [1], центр [2] - глаз [2]};

Опять очень случайный и работал до сих пор. Это как исчерпание памяти и просто переполнение. У кого-нибудь есть какие-либо идеи? Есть ли ограничение на размер класса?

Обычно я мог бы решить эту проблему, но я даже вернулся к рабочей версии и переопределил некоторый код, а затем он начал случайное поведение.

Я проверил на утечки, и я в порядке

ОБНОВЛЕНИЕ: Часть 2

Прямо в моем интерфейсе в моем файле .h у меня есть

GLfloat eye[3];

В моем .m я могу присвоить значение каждому элементу, и он отлично работает

Если я сделаю

NSLog(@"%f",eye[0]);

Вылетает. Почему это? (раньше работал)

Answer 1

• Если произойдет сбой (или сбой), будут следы. Опубликовать их.

• Попробуйте "построить и проанализировать". Исправьте все предупреждения, которые он вам дает. Исправьте все предупреждения, которые дает вам компилятор. Правильно написанное приложение должно компилироваться без предупреждений.

• почему __block в этой строке кода? Там, кажется, нет ничего связанного с этим.

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

<Ч />

Поскольку вы не пишете в request, нет никаких оснований отмечать эту переменную как __block. Так как __block приведет к сохранению request до , а не , возможно, объект преждевременно освобожден и освобожден. Может быть.

Как вы распределяете массивы с плавающей точкой?

Answer 2

Как объявляются центр и глаз?Это переменные экземпляра, глобальные или статические переменные?Возможно, каким-то образом память для этих массивов была освобождена к моменту обратного вызова (что также объясняет, почему происходит сбой строки, инициализирующей массив float).

Answer 3

EXC_BAD_ACCESS часто является признаком преждевременного освобождения (например, попытка получить доступ к освобожденному объекту, потому что он был освобожден слишком много раз).

все работало нормально [...] Теперь, кажется, умирает

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