Как iOS справляется с повреждением памяти из низкоуровневого кода C / Objective-C? - PullRequest
0 голосов
/ 03 июня 2019

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

Эффект в том, что длина буфера ниже может измениться.Я видел, как iOS выбрасывает EXC_BAD_ACCESS или EXC_BREAKPOINT в результате этих вызовов.

Мой вопрос: будет ли iOS всегда выдавать исключения, когда я неправильно использую memcpy, или будет жаловаться только тогда, когда я пишу за пределами моей разрешенной памяти?

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

NSData* buffer = ...
Byte *array = (Byte*)malloc(buffer.length);
memcpy(array, buffer.bytes, buffer.length);

1 Ответ

1 голос
/ 03 июня 2019

В последний раз, когда я проверял или имел такую ​​проблему, он будет жаловаться только тогда, когда у вас нет собственной памяти.В моей ситуации я писал поверх любых объектов, следующих за адресом, по которому пытался написать.Результатом было то, что казалось случайным падением на объектах, столь же несвязанных, как даже NSString.

Моя ошибка была чем-то вроде следующего:

MyStructure *myStructure = malloc(sizeof(myStructure)); // Incorrect
MyStructure *myStructure = malloc(sizeof(MyStructure)); // Fixed

Простая ошибка автозаполнения, которая приводила к долгим днямохота на эту ошибкуMyStructure было довольно большим, поэтому доступ к какому-либо свойству (как к чтению, так и к записи) в этом случае мог бы просто переполниться и прочитать / записать все, что было после него.Это в конечном счете случайно падает;иногда плохой доступ, иногда просто случайное исключение случайного объекта.

...