IAR 4.41A & C++ Опции

[mungo]

Имеем простой классический код:

Код

class    TMenu    {
public:
TMenu();
~TMenu();
int    Show(int);
private:
char    menu[7][17];
int    x,width,len,ptr;
};

TMenu *m=new TMenu();
m->Show(1);
delete m;

Компилируется отлично, без ошибок. Пишем в камень (AT91SAM7XC256), радуемся красивому зависанию. До оператора new все работает, затем просто виснет проц. Объявление в статике все решает, но держать в памяти много объектов не очень здорово. Писать для каждого нового меню отдельную процедуру, чтобы держать все в стеке тоже не очень - тогда с классами нет необходимости возиться.
Думал, что там с heap проблема - никаких. malloc() работает.

[mungo]

J-Link запустил с горем пополам. Короче нашел где ступор - когда вызывает new, заходит в malloc, после чего в abort где и находит бесконечный branch сам на себя.

[alexander55]

J-Link запустил с горем пополам. Короче нашел где ступор - когда вызывает new, заходит в malloc, после чего в abort где и находит бесконечный branch сам на себя.

Ну теперь дело за малым прошагать malloc, а затем понять, что надо что-то поменять в icf файле.

[mungo]

Ну теперь дело за малым прошагать malloc, а затем понять, что надо что-то поменять в icf файле.

В каком файле? Может в .xcl? Так там задано 8000 под HEAP. Статически распределено около 9 кило, 64 всего у камня.

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

Разобрался. По непонятной причине в оболочке писал 8000 хипа, а в файле было 100. Явно не хватало. И при этом все остальные параметры показывает правильно.

[zhevak]

Разобрался. По непонятной причине в оболочке писал 8000 хипа, а в файле было 100. Явно не хватало. И при этом все остальные параметры показывает правильно.

По горячим следам.
1. Посмотрел тут ARM® IAR C/C++ Compiler Reference Guide на стр. 13 есть очень короткая глава
Dynamic memory on the heap в ней раздел Potential problems. Сказано только как избежать исчерпания кучи, но не сказано, как ведут себя new. Не хорошо как-то... возникло чувство недоделанности не только руководства, но и самого компилятора. Жаль.

2. Ради спортивного интереса открыл к MSDN (MS VC++ 6.0)
"If there is insufficient memory for the allocation request, by default operator new returns NULL. You can change this default behavior by writing a custom exception-handling routine and calling the _set_new_handler run-time library function with your function name as its argument."
(Перевод мой)
"Если для запроса нехватает памяти, то поумолчанию оператор new возвращает NULL. Вы можете изменить такое поведение путем создания своей подпрограммы-обработчика исключения и вызова библиотечной функции _set_new_handler (имеется ввиду из ран-тайм бибиотеки) с именем Вашей функции в качестве аргумента."

2 mungo -- Спасибо за обозначенные грабли. Будем иметь ввиду.

Сообщение отредактировал zhevak - Sep 24 2007, 04:36

[Alexey Bishletov]

Сказано только как избежать исчерпания кучи, но не сказано, как ведут себя new. Не хорошо как-то... возникло чувство недоделанности не только руководства, но и самого компилятора. Жаль.

При исчерпании кучи new должен возвращать NULL. Так у всех, поэтому в руководстве про это и не писали. Можно добавить в программу проверку на NULL после new и вывод ошибки. Поможет избежать "загадочного" поведения.

[zhevak]

При исчерпании кучи new должен возвращать NULL. Так у всех, поэтому в руководстве про это и не писали. Можно добавить в программу проверку на NULL после new и вывод ошибки. Поможет избежать "загадочного" поведения.

Чуть выше

Короче нашел где ступор - когда вызывает new, заходит в malloc, после чего в abort где и находит бесконечный branch сам на себя.

А в самом первом посту

До оператора new все работает, затем просто виснет проц.

Я так понял, что new вообще не возвращает управление. Правда, это все со слов автора темы. Что там генерит ИАР-компайлер я не проверял -- нет под руками изделия, где бы можно было проверить отход опрератора new от всемирно принятых правил игры.

Добавлять проверку на NULL нужно обязательно!. Для коммерческих программ для компов я это делаю в обязательном порядке, хотя там памяти -- умотаться. Но кто его знает, а вдруг при длительной эксплуатации (несколько недель, месяцев) память исчерпается, и что тогда? Позорный BSOD?
А вот для АРМов проврека на NULL -- ну это просто жизненно необходимо!

[zltigo]

Добавлять проверку на NULL нужно обязательно!.

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

[zhevak]

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

Лифт -- О-о, эта аллегория мне нравится
Продолжим нашу священную "религиозную" войну.

Я только одного не могу понять. Почему разработчики ИАР-компилятора сделали поведение new несколько отличное от стандарта и при этом никак не удосужились описать его? Может я не там читал?

Почему архитекторы спроектировали такуй странный лифт, каждый раз входя в который нужно всегда убеждаться том, что он вообще является лифтом, а не сортиром -- "вошел и провалился". Что до меня, так после таких дел я вообще не хочу пользоваться в ИАРе этим лифтом (new).

[alexander55]

я вообще не хочу пользоваться в ИАРе этим лифтом (new).

Я стараюсь не пользоваться им везде.
Я говорил ему, чтобы не мешал водку с портвейном. А он....у-у-у хипи волосатый. (Осенний марофон).