new и delete в IAR (ARM) Опции

[0x435641]

столкнулся со странными вылетаниями программы в swi_handler и data_handler
в проекте активно используется динамическая память, Ethernet, USB
долгими мучительными копаниями удалось найти причину - параллельное выполнение сабжевых операторов, которые используются как в основном цикле, так и в прерываниях

на данный момент решил вопрос отключением прерываний, если new и delete вызываются вне прерывания

в нете не нашел инфы по спицифике использования этих операторов в IAR

если кто-то обладает знаниями - просьба поделиться

[Непомнящий Евген...]

Насчет iar - не знаю, gcc - newlib под bare metal содержит нереентерабельные malloc/free (на которых основаны new/delete)

У тебя вероятно то же самое.

Как вариант, можешь переопределить глобальные new и delete (как обычные, так и для массивов) и лочить прерывания перед вызовом malloc/free.

Возможно, в iar есть готовые заглушки, переопределив которые можно добиться реентерабельности

[0x435641]

Насчет iar - не знаю, gcc - newlib под bare metal содержит нереентерабельные malloc/free (на которых основаны new/delete)

У тебя вероятно то же самое.

Как вариант, можешь переопределить глобальные new и delete (как обычные, так и для массивов) и лочить прерывания перед вызовом malloc/free.

Возможно, в iar есть готовые заглушки, переопределив которые можно добиться реентерабельности

это вероятные догадки... хотелось бы документального подтверждения

[Непомнящий Евген...]

читай доку
к иару кстати исходники библиотек прилагаются, посмотри их

[KSN]

Почитайте "IAR C/C++ Compiler Compiling and Linking", там и про new и про delete есть. Использование динамического выделения памяти в прервываниях - не лучший вариант с позиции оптимизации. Лучше избегать этого.

[MALLOY2]

это вероятные догадки... хотелось бы документального подтверждения

На странице 390 мануала все написано, что эти функции не реентерабельны. Защищайте их сами семафорами или мутексами ну или свой менагер.

REENTRANCY
A function that can be simultaneously invoked in the main application and in any
number of interrupts is reentrant. A library function that uses statically allocated data is
therefore not reentrant.
Most parts of the DLIB library are reentrant, but the following functions and parts are
not reentrant because they need static data:
● Heap functions—malloc, free, realloc, calloc, and the C++ operators new
and delete
● Locale functions—localeconv, setlocale
● Multibyte functions—mbrlen, mbrtowc, mbsrtowc, mbtowc, wcrtomb,
wcsrtomb, wctomb
● Rand functions—rand, srand
● Time functions—asctime, localtime, gmtime, mktime
● The miscellaneous functions atexit, strerror, strtok
● Functions that use files or the heap in some way. This includes printf, sprintf,
scanf, sscanf, getchar, and putchar.
Functions that can set errno are not reentrant, because an errno value resulting from
one of these functions can be destroyed by a subsequent use of the function before it is
read. This applies to math and string conversion functions, among others.
Remedies for this are:
● Do not use non-reentrant functions in interrupt service routines

[0x435641]

нашел, спасибо за наводку!

выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ???
или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания?

Сообщение отредактировал 0x435641 - Mar 19 2013, 10:03

[Непомнящий Евген...]

ты не должен вызывать new/delete (malloc/free) прямо или опосредованно одновременно из нескольких потоков. Если ты так делаешь - добавляй средства синхронизации - к примеру запрещай прерывания

[0x435641]

>выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ???
>или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания?

меня интересует сейчас конкретно sprintf. он в основном потоке. я могу в прерывании пользовать new/delete, или тоже синхронизация нужна? в потрохах sprintf не ковырялся

[MALLOY2]

для new/delete синхронизация нужна полюбому, и для sprintf нужна если он вызывается с нескольких мест (задач или прерываний) он может не долько динамичсескую использоватьи татическую тоже дак что new/delete сам посибе и sprintf тоже.

[jcxz]

sprintf не использует динамическую память - не надо фантазий.
Но использует много стека, так что использовать его в ISR-ах, имхо, - моветон.
Да и вообще имхо - надо всегда стараться избегать динамической памяти в эмбеддед.

для new/delete синхронизация нужна полюбому, и для sprintf нужна если он вызывается с нескольких мест (задач или прерываний) он может не долько динамичсескую использоватьи татическую тоже дак что new/delete сам посибе и sprintf тоже.

Тоже фантазии. sprintf не использует ни динамическую ни статическую память, все хранит в автоматической, т.е. - полностью реерентерабелен. Но объём на стеке использует большой.