In den letzten Jahren hat die (eingebettete) Software, mit der ich gearbeitet habe, die Verwendung von malloc() im Allgemeinen nicht zugelassen. Die einzige Ausnahme ist, dass sie während der Initialisierungsphase zulässig ist, aber sobald entschieden wird, dass keine weiteren Speicherzuweisungen mehr erlaubt sind, schlagen alle zukünftigen Aufrufe von malloc() fehl. Da der Speicher durch malloc()/free() fragmentiert werden kann, ist es in vielen Fällen schwierig zu beweisen, dass künftige Aufrufe von malloc() nicht fehlschlagen werden.
Ein solches Szenario trifft auf Ihren Fall möglicherweise nicht zu. Dennoch kann es nützlich sein, zu wissen, warum malloc() fehlschlägt. Die folgende Technik, die wir in unserem Code verwenden, da malloc() nicht allgemein verfügbar ist, könnte (oder könnte auch nicht) auf Ihr Szenario zutreffen.
Wir neigen dazu, uns auf Speicherpools zu verlassen. Der Speicher für jeden Pool wird während der transienten Startphase zugewiesen. Sobald wir die Pools haben, holen wir uns einen Eintrag aus dem Pool, wenn wir ihn brauchen, und geben ihn wieder an den Pool zurück, wenn wir fertig sind. Jeder Pool ist konfigurierbar und normalerweise für einen bestimmten Objekttyp reserviert. Wir können die Nutzung jedes Pools im Laufe der Zeit verfolgen. Wenn uns die Pool-Einträge ausgehen, können wir herausfinden, warum. Ist dies nicht der Fall, haben wir die Möglichkeit, unseren Pool zu verkleinern und Ressourcen zu sparen.
Ich hoffe, das hilft.