Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document realloc/free being not interrupt safe #6428

Closed
6 tasks done
devyte opened this issue Aug 19, 2019 · 0 comments
Closed
6 tasks done

Document realloc/free being not interrupt safe #6428

devyte opened this issue Aug 19, 2019 · 0 comments
Assignees
Milestone

Comments

@devyte
Copy link
Collaborator

devyte commented Aug 19, 2019

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it.
  • I have filled out all fields below.

Platform

All

Settings in IDE

All

Problem Description

With #6274, several critical section flaws were uncovered. Among them is the fact that it is not safe to use realloc() or free() from within an ISR, except maybe under very specific conditions.

At this time, there doesn't appear to be a way to make them safe, so the recommendation is: don't use them in an ISR, unless you know very well what you're doing.
"Don't use them" includes adding elements to mem-managed objects with contiguous memory, such as String, std::string and std::vector, as well as any user-implemented objects that could internally manage an array or similar.

I think use of malloc is ok from an ISR. Therefore, adding elements to mem-managed objects with non-contiguous memory should be ok, e. g. std::list, std::forward_list, std::map, etc.

Use of malloc et al from ISRs or signal handlers is not supported even in full OSs like Linux (malloc is thread safe but not interrupt safe), so this non-safety shouldn't be news to programmers. Even so, the above needs to be documented for full clarity. This issue is meant to track that.

@devyte devyte self-assigned this Aug 19, 2019
@devyte devyte added this to the 2.6.0 milestone Aug 19, 2019
earlephilhower added a commit to earlephilhower/Arduino that referenced this issue Sep 27, 2019
Adds a section on interrupts to the docs and lists the restrictions
and warnings about running long tasks.

Fixes esp8266#6428
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant