Crash in free()

У меня есть несколько отчетов о сбоях от приложения iOS, которое происходит из SIGABRT в вызове free().Crash in free()

Стек вызовов соответствуют:

0 libsystem_kernel.dylib    0x3863c1f0 __pthread_kill + 8 
1 libsystem_c.dylib     0x385ecfdd abort + 77 
2 libsystem_malloc.dylib    0x38664d67 free + 383

Я пытаюсь получить больше диагностика, но в то же время, кто-нибудь столкнуться с таким же? Какой неправильный аргумент вызовет вызов free()? Я вижу несколько вариантов:

~~пустой указатель~~(actually legit)
указатель области данных (то есть строковый литерал)
стек указатель
указатель мусора (т.е. неинициализированная один)
указатель кучи, который уже был освобожден

Любые идеи, пожалуйста? Это довольно редко, последний был в сентябре '14. Но у меня более 10 баллов, вероятно, там есть ошибка.

источник

2015-03-10 Seva Alekseyev

Другие значения также вызовут проблемы, очень любой указатель не-NULL, который ранее не возвращался 'malloc',' calloc' или 'realloc' или уже был свободен' free' или 'realloc'. Используйте valgrind, чтобы попытаться найти проблему. – chqrlie

Он пришел из пользовательских телефонов, я понятия не имею, как воспроизвести его. Если бы я мог воспроизвести, я не буду задавать этот вопрос :) –

Я бы начал с кода и инициализировал все указатели C/C++ равными 0 (NULL). Если вы освободите что-либо, установите указатель на 0. Проверьте весь свой код, который выполняет удаление (C++) или бесплатно (C). Проверяйте любые массивы, которые вы пишете, чтобы убедиться, что вы не идете по концу. Ошибка вызывается при попытке и освобождении() указателя, который не имеет соответствующей записи выделения. Скорее всего, неинициализированный указатель или один уже освобожден, но не установлен на 0, или что-то случайно перешагнуло и исказило действительный указатель. Поскольку вы не можете его воссоздать, вы не можете многое сделать. –

Если я правильно прочитал дамп стека, код вызвал утверждение в free и вызвал abort. Посмотрите исходный код для libsystem_malloc на http://opensource.apple.com и попытайтесь понять, какое утверждение не удалось.

У вас есть бродячий указатель, угадывая, где он прячется от одного невоспроизводимого сбоя, почти невозможно. Запуск приложения в эмуляторе с помощью valgrind (если это возможно) может помочь вам отслеживать неправильное использование памяти.

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

источник

2015-03-10 20:53:13 chqrlie

Где в источниках можно было бесплатно() быть, пожалуйста? –

http://www.opensource.apple.com/source/Libc/Libc-594.1.4/gen/malloc.c является источником распределения памяти Apple. Я не уверен, что он используется в iOS. Найдите источник для 'free', вы увидите, что это вызовы' abort', если он не может найти зону для переданного указателя. Это немного уменьшает ошибку: маловероятно, что уже освобожден указатель, а также указатель внутри части выделенных данных. – chqrlie

Кроме того, в первой строке есть нулевая проверка. Лучше, чем ничего ... –

Crash in free()

ответ

Смежные вопросы