Перейти к содержанию
    

STM32F103RET6 уходит в HardFault_Handler

Скорее всего, для инициализации того, что выделено из кучи, используется стек.

Вообще не представляю как это возможно!

 

У Вас есть указатель стека, который перемещается каждый раз при вызове продпрограмм. По этому указателю записываются адреса возвратов, локальные переменные и т.д.

 

И вот в какой-то момент одна из функций запрашивает кусочек памяти. Указатель сдвигается, т.к. следующий оператор, допустим вызов еще какой-нибудь функции... Пока все нормально. Потом, допустим, вы возвращаемся из нескольких вложенных функций, но при этом кусок памяти не отдаем системе. Он все еще нам нужен! Потом опяит следуют вызовы, которые приближают указатель стека к началу нашего выделенного участка памяти... Вы понимаете проблему? Кто-то же должен сказать стеку "Э-э, парень! Стоп! Дальше идет выделенный кусок памяти, ну-ка прыгай вверх на 512 байт"

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вообще не представляю как это возможно!

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

У меня в функции, инициализирующей ЖКИ, использовался массив констант. Пока я не задал ему квалификатор static, этот массив сначала создавался в стеке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня в функции, инициализирующей ЖКИ, использовался массив констант. Пока я не задал ему квалификатор static, этот массив сначала создавался в стеке.

Ну да, все правильно. static переводит переменную из разрядя автоматических (созданных) на стеке, в разряд статических, созданных в оперативе до запуска main(). Тут все понятно.

 

Но куча (heap)? Тут же совсем другие механизмы выделения памяти работают.

Или мы о чем с Вами говорим? У меня такое чувство, что о разном.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну да, все правильно. static переводит переменную из разрядя автоматических (созданных) на стеке, в разряд статических, созданных в оперативе до запуска main(). Тут все понятно.

 

Но куча (heap)? Тут же совсем другие механизмы выделения памяти работают.

Или мы о чем с Вами говорим? У меня такое чувство, что о разном.

У меня были константы (static const), и брались в этом случае из Flash.

Это, наверное, другое.

Вопрос, как дальше использовалась память, выделенная с помощью malloc. Я только предположил, что для инициализации используется стек.

А что, если самой malloc() требуется стек?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А сейчас у меня вопрос. Если в куче не осталось свободного пространства или она изначально равна нулю, то почему malloc() возвращает валидный указатеь, т.е. не NULL?

Где этот нулевой размер heap задается у вас?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос, как дальше использовалась память, выделенная с помощью malloc. Я только предположил, что для инициализации используется стек.

Не думаю, что область памяти, выделяемая с помощью malloc() из кучи, хоть как то инициализируется.

Это уже забота программиста.

Задача malloc() - просто предоставить блок свободной памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я только предположил, что для инициализации используется стек.

А что, если самой malloc() требуется стек?

Неверное предположение. Извините.

Самой функции malloc() для работы наверняка требуется стек. Хотя я не смотрел на ее исходные коды, и поэтому могу ошибиться. Но это не важно -- нужен ей стек для ее переменных или нет. Важно, что когда функция возвращает управление, ее стековый кадр перестает существовать. А значит, что нас совершенно не касается, что там она у себя внутри делает (если она все делает согласно своему описанию). Не думайте, что выделение и освобождение памяти -- это что-то сверхъестественное. Там все достаточно просто и особого изврата нет. Изврат начинается на стороне программиста, когда тот пытается записать по адресу, память которого уже отдана в общий пул памяти (возвращена в кучу), или когда программист забывает вернуть эту память. Один раз не пид... можно. Но если прога в цикле забирает память и не возвращает? В конце концов прога когда-нибудь да исчерпает всю память. (Мне в этом отношении нравится Линуксовый подход. -- Пестня! Попробуйте сотряпать прогу, которая постепенно сжирает память и посмотрите на реакцию системы. Уверяю -- получите удовольствие! Хотя... извините, Остапа опять пенесло!)

 

Не думаю, что область памяти, выделяемая с помощью malloc() из кучи, хоть как то инициализируется.

Это уже забота программиста.

Задача malloc() - просто предоставить блок свободной памяти.

Вот именно -- не инициализируется! И это единственное правильное решение. Зачем память инициализировать? Чем ее инициализировать? Нулем? 0xFF-ами? Чем??? -- Ну откуда malloc() знает, что там собирается делать программер. А поскольку любая инициализация так или иначе потребует процессорного времени, то зачем его трать, если нам нужна не такая, а какая-то другая инициализация? Вот поэтому malloc() только выделяет кусок памяти и более ничего не делает. Ну разве что перед тем как это сделать, она проверяет а вообще сможет-ли она выделить непрерывный кусок памяти запрошенного размера. Если сможет, то помечает его границы (записывает особые отметки в пограничные участки) и возвращает пользователю начальный адрес куска.

 

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

 

Хех. Меняю свой опыт на вашу молодость.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Неверное предположение. Извините.

Я ж не сказал, что сама malloc() инициализирует выделенную память, а что она инициализируется потом, когда функция, которая запросила память, начинает ее использовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...