Dynamic memory allocation challenges in safety critical systems
summary
Explores how ISO 26262 and recent MISRA/Autosar guidance forbid dynamic allocation after init and why: demos use readelf, objdump and GDB plus GitHub examples to show the heap using brk vs mmap, lazy allocation via mmap vs brk, and that the stack grows but never shrinks on recursion. Measures: make_unique triggers ~4 bytes, make_shared adds ~24 bytes for control block, stack_trace consumes ~512 bytes; shows global and per-class operator new/delete, C malloc/free, and PMR monotonic/null memory_resource.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:12Safety critical systems defined
- 6:52ISO 26262 dynamic allocation rules
- 11:23Static vs dynamic allocation
- 18:36Stack growth and heap quirks
- 25:43Hardware memory hierarchy
- 27:51C++ memory model
- 30:18New and delete expressions
- 35:37Alignment and no-throw new/delete
- 38:28Alternative allocation methods
- 43:02Detecting allocation in libraries
- 45:11Custom allocation mechanisms
- 49:48Custom allocators and PMMR
- 53:47Summary
related talks
01h 03mTaming dynamic memory
37mTrack your memory allocation
06mUsing PMR in C++ Embedded Systems for Functional Safety
50mTwo advanced PMR techniques in C++17/20
29mWrangling memory leaks where you thought they could never happen
32mThe Impact of Memory Allocators on Performance: A Deep Dive
01h 03mLifetime Safety in C++: Past, Present and Future
59mIntroduction to unsafe C#: Calling native code and crashing in entirely new ways