Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Размер оставшейся "кучи"
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
tobias_ivan
Необходимо для контроля утечки памяти.
Модет кто знает, как это сделать в IAR?
IgorKossak
Сложность в том, что куча это не стек, она может быть сильно фрагментирована.
Для точного определения количества и размера свободных кусков надо знать формат распределения памяти в куче.
В простейшем же случае, когда предполагается, что вся память в куче должна быть освобождена, можно попытаться выделить массив размером с кучу минус служебные байты и по результату этой операции судить - есть ли утечка памяти.
tobias_ivan
А менеджер кучи, обслуживающий операторы new и delete в IAR, не владеет информациией о количестве выделенных байт? Фрагментацией пока пренебрегаем.
BVU
Куча понятие 'программное' (виртуальное по сравнению с архитектурой и работой контроллера - железа), поэтому программист сам должен выбрать тот или иной метод ее контроля, например как это делается в ОС (allocate, deallocatr и прочее...). Так что IAR здесь как продукт разработки совершенно не причем.
tobias_ivan
Цитата(BVU @ Oct 26 2006, 13:32) *
Так что IAR здесь как продукт разработки совершенно не причем.

Как среда разработки(, компилятор, линкер) - да, может не корректно поставлен вопрос...

Реализация, используемых new и delete, скрыта в библиотеках, поставляемых с IAR. Менеджер распредения кучи - там же. Вопрос как раз касается этого менеджера, предоставляющего функции new и delete.
Цитата(BVU @ Oct 26 2006, 13:32) *
...поэтому программист сам должен выбрать тот или иной метод ее контроля...

Создавать собственный менеджер кучи - задача не оплачиваемая.
tobias_ivan
В продолжении темы, может кто встречался с этим:
Код
  unsigned char *buf = NULL;
  buf = new unsigned char[65535];
  if (buf == NULL)
  {
    rprintfStr("No such memory...\n\r");
  }
  else
  {
    rprintfStr("Delete allocated ...\n\r");
    delete[] buf;
  }

НЕ работает, программу клинит при вызове new, если фактически памяти недостаточно. Если new заменяю

Код
(unsigned char *)malloc(65535);

Работает корректно.
Никто не подскажет, что это такое и как это побороть?
zltigo
Цитата(tobias_ivan @ Nov 17 2006, 17:16) *
Никто не подскажет, что это такое и как это побороть?

Не использовать new() по причине нахренненужности ибо для new() не предусмотрено ошибки возвращать :-).
Чаще всего делают тупое ожидание до освобождения памяти или городить к нему exception.
Вообще почитайте подробнее про new(). Да и на данном форуме раза три сие уже обсуждалось.
IgorKossak
Цитата(tobias_ivan @ Nov 17 2006, 14:16) *
...НЕ работает, программу клинит при вызове new, если фактически памяти недостаточно. Если new заменяю

Код
(unsigned char *)malloc(65535);

Работает корректно.
Никто не подскажет, что это такое и как это побороть?

Переопределите new()
Код
void *operator new(size_t sz)
{
    void *p = malloc(sz);
    return p;
}

void *operator new[](size_t sz)
{
    return operator new(sz);
}
tobias_ivan
Цитата(IgorKossak @ Nov 20 2006, 10:51) *
Переопределите new()


А как быть с классами? При выделении памяти вызывается конструктор.

Мне предложили произвести замену таким образом:

Код
MyClass *myclass = (MyClass*)malloc(sizeof(MyClass));
if (myclass == NULL)
{
  return error;
}
myclass->MyConstructor();


Но много перелопачивать надо.
Нельзя ли здесь припаять переопределение...?
zltigo
Цитата(tobias_ivan @ Nov 20 2006, 13:24) *
А как быть с ....

Читаем:
http://electronix.ru/forum/index.php?showt...hl=new&st=0

обращая внимание на set_new_handler()
tobias_ivan
Цитата(zltigo @ Nov 20 2006, 18:32) *
Цитата(tobias_ivan @ Nov 20 2006, 13:24) *

А как быть с ....

Читаем:
http://electronix.ru/forum/index.php?showt...hl=new&st=0

обращая внимание на set_new_handler()


Афигеть, именно это и происходит:
Цитата
А вот то, что из new не предусмотрен возврат в случае отсутствия памяти, это дополнительный
прикол :-)


А откуда такая информация?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.