Имеется ли разница в последовательности вызовов malloc и free?

p1 = malloc(...);
p2 = malloc(...);

free(p1);
free(p2);

В программе утечек памяти нет. Все вызовы malloc-free комплементарны (проверено переопределением malloc-free)
что free не применяется дважды к одной и той же области памяти , realloc проверен на предмет применения
к левым областям памяти - всё нормально.


но некоторые из завершающих free выдают ошибку разрушения кучи (heap). Что может быть не так???

Как они это выдают? Насколько я помню, то вызов free() ничего не возвращает.

Попробуйте подобный код запустить на "большом" компьютере, если будет аналогичное поведение, или например ошибка сегментации, значит что-то в программе не так.

Дебажить, дебажить и ещё раз дебажить...
Я бы чисто из суеверных соображений free вызывал в обратной последовательности малоку:-)
А если серьёзно, то для Вашего примера всё должно быть едино.

Разницы в последовательности вызовов malloc - free нет. Важно только, чтобы malloc вызывалась перед free. Проблемы могут возникнуть если нет проверки результата выполнения malloc, т.е. функция не сумела получить доступ к запрашиваемой динамической памяти.

Модератор (rezident). В очередной раз отмечаю нарушение Вами п.3.4 Правил форума.

Функции malloc и free заставлены говорить в визуал студио путём использования выводов в стандартную консоль stdout сообщений о неправильных указателях и др.

Всем спасибо, прояснилось.

После вызова free происходит обращение на чтение или запись к удалённой области памяти - при этом, возникает программное исключение результатом которого является debug-сообщение в консоль.
Теперь надобно по адресу определить в какой строке кода происходит чтение или запись с учётом динамически изменяемого базового адреса сегмента данных... что осложняет отладку.

Если это ошибка разрушения кучи - вы пишите мимо выделенных областей, затирая служебную информацию. Но это и так ясно.
Как можно найти место: переопределяете malloc и free макросами, которые вызывают нормальные функции и тоже пишут в консоль сообщение и номер строки. После вылета увидите последнее действие, ищите где-то рядом.

А нельзя запустить прогу в дебаггере студии? Там было бы видно, что где, по call-stack.

Лучший вариант. А есть еще такая отличная вещь : vld (Visual Leak Detector http://www.codeproject.com/KB/applications...kdetector.aspx). Он вам вообще все расскажет и покажет.

А под GCC, подобного ничего нету?

Так и сделал с использованием __LINE__ и __FILE__ помимо всего прочего реализовал массив вызовов (стек) использования пар malloc-free и realloc-free.

При вызове free записывал высвобождаемый фрагмент в локальную кучку и сравнивал все фрагменты после выхода из программы - если сегмент в оригинальной памяти был повреждён (запись), то это сразу стало явным. Потом выделить нужный фрагмент кода- дело техники: точка остановки по записи в память.

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

Хотя наверняка можно обыграть "переопределив" на С операцию индексирования [] функцией получения по индексу.

Но это уже скорее С++ с его ad-hoc полиморфизмом.