[riot-notifications] [RIOT-OS/RIOT] Preemption of malloc on AVR (#10842)

Marian Buschsieweke notifications at github.com
Tue Jan 22 13:21:06 CET 2019

#### Description
[This post](https://www.mail-archive.com/avr-libc-dev@nongnu.org/msg06263.html) in the AVR libc development email list describes that memory corruption can occur on FreeRTOS when a call to `malloc()` or `free()` is preempted. They suppose to address this by adding hooks at the beginning and end of `malloc()` and disable preemption while `malloc()` or `free()` works on the allocator structures.

As the AVR libc does not have those hooks yet, I don't see any way how any OS using preemption can work reliable when `malloc()` is called. So I believe the same problem applies to RIOT as well.

#### Steps to reproduce the issue
Have one thread call `malloc()` or `free()` and let this thread be preempted by a second thread while `malloc()` or `free()` was working on the allocator structures. If the second thread also accesses the allocation structures (e.g. by calling `malloc()` or `free()`), it might find those structures in a corrupted state.

#### Expected results
The call to `malloc()` or `free()` should not be preempted in order to keep the allocator structures in a useable state.

#### Actual results
`malloc()` and `free()` is not protected against preemption, so preemption could lead to one thread accessing the allocator structures in a corrupted state.

#### Versions
Should apply to any version of RIOT using any avr-libc version including the (as of now) most recent version.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190122/ea9b9f19/attachment.html>

More information about the notifications mailing list