Почему

На данный момент это частичный ответ, в основном в отношении:

Почему malloc() никогда не возвращает NULL?

Таким образом, Due, по-видимому, использует Newlib в качестве своей реализации libc; это среда выполнения systems C (стандартная и некоторые нестандартные), которая включает malloc()или большую часть malloc() в любом случае. Newlib malloc() полагается на функцию sbrk(), которая реализуется конкретной системой, должной в данном случае. Это имя и основная идея исходят из Unix; вы можете прочитать о взаимодействии между malloc и sbrk some без необходимости связывать его с Newlib или Due конкретно. Короче говоря, sbrk расширяет область, с которой должен работать malloc, и malloc делит эту область на запрошенные куски. Вот документация Newlib для sbrk и пример реализации.

Ядро Due (SAM) для Arduino реализует sbrk следующим образом:

extern caddr_t _sbrk ( int incr )
{
    static unsigned char *heap = NULL ;
    unsigned char *prev_heap ;

    if ( heap == NULL )
    {
        heap = (unsigned char *)&_end ;
    }
    prev_heap = heap;

    heap += incr ;

    return (caddr_t) prev_heap ;
}

Это своего рода дегенеративная реализация _sbrk, которая просто слепо говорит: "Вы хотите больше памяти, конечно, здесь вы идете" без ограничений. Если вы посмотрите на пример реализации sbrk для Newlib, вы увидите, что он просто вызывает abort() вместо правильного сбоя, который приведет к тому, что malloc вернет NULL, что, по общему признанию, не очень хорошо, но, по крайней мере, он не притворяется, что все в порядке.

Где-то в этом коде должно быть условие, которое проверяет, есть ли еще место, и устанавливает errno = ENOMEM и эффективно возвращает -1, если его нет.

Я изменил этот код, чтобы позволить мне установить переменную из скетча, которая может привести к сбою следующего вызова _sbrk, как описано выше. И конечно же, при следующем вызове malloc() он вернул NULL, потому что _sbrk указал на сбой.

Таким образом, реализация _sbrk, предоставляемая ядром Due / sam, должна быть изменена таким образом, чтобы malloc терпел неудачу, когда это необходимо. Тем не менее, я не совсем уверен, как это следует сделать. Поэтому я воздержусь от конкретных рекомендаций по этому поводу. Может быть, я посмотрю на это больше, я вернусь и обновлю это чем-то более полезным, обратившись к вашему другому вопросу:

Как узнать, что память исчерпана?

Однако в грубых терминах ответ будет заключаться в том, что вы измените эту функцию так, чтобы она возвращала -1 с ENOMEM при правильных условиях.

---

Как

Это ранее упомянутое обновление с некоторыми подробностями о том, как:

Как узнать, что память исчерпана?

Поэтому я сделал кое-что, чтобы дать вам представление о том, как будет выглядеть это состояние. Я не рекомендую вам строго использовать его; во-первых, он почти не был протестирован.

Из таблицы семейства ATSAM3X8E:

SR 0 доступен по системной шине Cortex-M3 по адресу 0x2000 0000 , а SR1 - по адресу 0x2008 0000. Пользователь может видеть SRAM как непрерывный благодаря зеркальному эффекту, давая 0x2007 0000 - 0x2008 7FFF для SAM3X / A8

Указатель стека начинается в верхней части памяти 0x2008 7FFF и растет вниз. Символ _end обозначает конец изменяемых переменных длительности статического хранения или начало кучи. Где-нибудь поближе к 0x2007 0000; чем меньше этих переменных, тем ближе.

В этой системе, которая имеет довольно распространенную компоновку, куча растет с положительным приращением до sbrk по мере того, как указатель стека уменьшается с кадрами стека (локальными переменными, адресами возврата и т. Д.). Таким образом, "конец" памяти происходит, когда куча в противном случае распределяется по стеку или стек попадает в кучу, когда вы толкаете на нее вещи.

Поэтому обычно нужно проверить, приведет ли аргумент sbrkк тому, что край кучи окажется "слишком близко" к стеку.

В /.arduino15/packages/arduino/hardware/sam/ 1.6.12/core/arduino/syscalls_sam3.cя включил некоторые дополнительные заголовки:

#include <errno.h>
#include <stdlib.h>

И поставьте в качестве замены _sbrk() следующее:

size_t __malloc_margin = 4 * (size_t)1024;
extern caddr_t _sbrk (int incr) {
    static const unsigned char *       heap      = (unsigned char *)&_end ;
    /****/ const unsigned char * const prev_heap = heap;

    if (incr > 0) {
        // Дополнительные проверки для роста стека


        if (incr >= 96 * (size_t)1024) {
            // Due имеет только 96K оперативной памяти,
            // поэтому любой запрос на 96K или больше
            // - это провал за воротами.
            errno = ENOMEM;
            return (caddr_t)-1;
        }

        unsigned char *stack_ptr;

        asm volatile(
            "mov %[sp_out], sp"
            : [sp_out] "=r" (stack_ptr)
            :
        );

        if (stack_ptr < heap) {
            // We're already in real trouble.
            abort();
        }

        if (stack_ptr - heap  <  incr + __malloc_margin) {
            // Недостаточно памяти, учитывая запас прочности.
            errno = ENOMEM;
            return (caddr_t)-1;
        }
    }

    heap      += incr ;
    return (caddr_t) prev_heap ;
}

__malloc_margin использовался в качестве имени переменной только потому, что это имя avr-libc использует для той же цели, а именно для настройки минимального расстояния между стеком и кучей во время выделения, которое должен увеличить разрыв. Кстати, вы можете видеть, что такая же проверка происходит в реализации avr-libc malloc (которая также принимает роль sbrk.) Почему __malloc_margin 4K ? Никаких по-настоящему научных причин. Это около 4% памяти, так что она невелика, и для меня не совсем немыслимо, что кто-то попытается поместить локальную переменную (ы), приближающуюся к 4k, в кадр стека в системе с общей памятью 96kb. Однако 4K может быть неподходящим значением по умолчанию; об этом следует подумать подробнее. Наличие его в такой переменной позволяет настраивать его во время выполнения; обычно для него существует заголовок, который предоставляет объявление extern.

Я могу добавить больше позже, чтобы объяснить, но это коротко, если разрыв увеличивается, этот sbrk смотрит, попадет ли новый разрыв в __malloc_margin указателя стека по запросу, и если он вернет значение -1 и errno = ENOMEM, чтобы заставить malloc ведите себя правильно с точки зрения пользователя.

Прежде чем кто-нибудь потрудится упомянуть: Да, я знаю, что вы можете взять локальный адрес, чтобы получить значение указателя стека. Да, проверка того, не превышает ли однократное выделение 96K, вероятно, не нужна. Да, в нем есть что-то конкретное, хотя это не совсем так; вероятно, есть идентификаторы, которые можно было бы использовать вместо этого. Вероятно, он должен прервать (), если sbrk попытается опуститься ниже кучи размером 0. Это просто несколько рабочая иллюстрация того, что должно быть в _sbrk(). Больше размышлений и по крайней мере одно изменение должно быть внесено в него перед общим использованием.

Что касается abort()

Мне приходит в голову, что в некоторых случаях abort() может быть подходящим способом справиться с этим. Если вы считаете, что можете охарактеризовать систему (или скетч, если хотите) во время выполнения настолько хорошо, что сбой malloc() можно рассматривать как серьезную оплошность, то вызов abort() в sbrk() может иметь смысл. Или, по крайней мере, предоставить возможность сделать это.

В комментариях вы спросили:

Что именно abort() [делает] на Должном?

Ну, в документации Newlib говорится:

Перед завершением программы abort вызывает исключение SIGABRT (используя ‘raise (SIGABRT)’).

а потом еще ниже:

Необходимые вспомогательные подпрограммы ОС: _exit и, опционально, write.

Части SIGABRT и _exit - это более или менее стандартное поведение. Таким образом, он вызовет ваш обработчик сигнала для SIGABRT, если он у вас есть.

Итак, что же делает _exit? Это длится вечно.

Я вызвал abort() в скетче и сбросил следующее через arm-версию binutils objdump с параметрами командной строки -dS.

Вот соответствующий код abort():

00081b98 <abort>:
   81b98:   b508        push    {r3, lr}
   81b9a:   2006        movs    r0, #6
   81b9c:   f000 fb5c   bl  82258 <raise>
   81ba0:   2001        movs    r0, #1
   81ba2:   f7fe fec5   bl  80930 <_exit>
   81ba6:   bf00        nop

bl <raise>, в свою очередь, вызовет ваш обработчик сигнала. а bl <_exit> вызывает exit, который отображается следующим образом:

00080930 <_exit>:

extern void _exit( int status )
{
   80930:   e7fe        b.n 80930 <_exit>

00080932 <_kill>:

    for ( ; ; ) ;
}

Похоже, оптимизатор объединил здесь некоторые вещи, но по сути _exit имеет инструкцию, которая перескакивает (разветвляется) на себя, эквивалентную for(;;);.

Я наполовину ожидал abort(); код для отключения прерываний перед вызовом _exit(). Если вы планируете abort() в своем _sbrk(), об этом стоит подумать. Вы также можете указать глобальный флаг, который можно проверить из SIGABRT, что позволяет обработчику сигнала делать что-то диагностически подходящее специально для сбоев _sbrk().
Возможно, sbrk следует установить флаг в разделе данных no-init, а затем установить сторожевой таймер и позволить ему истечь (или предоставить обработчику SIGABRT информацию для этого). Есть много вещей, которые нужно обдумать.