-
Notifications
You must be signed in to change notification settings - Fork 13.3k
umm_poison false positive from ISR #8914
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
Conversation
The umm_poison logic runs outside the UMM_CRITICAL_* umbrella. When interrupt routines do alloc calls, it is possible to interrupt an in-progress allocation just before the poison is set, with a new alloc request resulting in a false "poison check fail" against the in-progress allocation. The SDK does mallocs from ISRs. SmartConfig can illustrate this issue.
Any reason not to move currently separate |
The current upstream umm_malloc has umm_poison as an outer wrapper. Without searching through all the old stuff, it used to be more mixed together. I have already started to blur that separation with |
Corrected missed edit in build path for UMM_REALLOC_MINIMIZE_COPY.
Bug introduced with PR fix esp8266#8914. When a reallocated pointer could not grow in place, a replacement allocation was created. Then UMM_POISON was written to the wrong block.
Bug introduced with PR fix esp8266#8914
* Fixes occasional UMM_POISON failure Bug introduced with PR fix #8914. When a reallocated pointer could not grow in place, a replacement allocation was created. Then UMM_POISON was written to the wrong block. * Fix umm_poison data corruption on realloc when memory move is used. Bug introduced with PR fix #8914 * refactored to resolve unused error in some build contexts
The umm_poison logic runs outside the UMM_CRITICAL_* umbrella. When interrupt routines do alloc calls, it is possible to interrupt an in-progress allocation just before the poison is set, with a new alloc request resulting in a false "poison check fail" against the in-progress allocation. The SDK does mallocs from ISRs. SmartConfig can illustrate this issue, see esp8266#3494 (comment) Other Sketches built with Debug: "Serial," that use the SDK's Promiscuous callbacks are also likely to encounter problems. The SDK support for "Promiscuous Receive" allocates memory from an ISR context, occasionally interrupting the poison wrapper code before it finishes setting the poison fences resulting in a false poison failed event.
* Fixes occasional UMM_POISON failure Bug introduced with PR fix esp8266#8914. When a reallocated pointer could not grow in place, a replacement allocation was created. Then UMM_POISON was written to the wrong block. * Fix umm_poison data corruption on realloc when memory move is used. Bug introduced with PR fix esp8266#8914 * refactored to resolve unused error in some build contexts
The umm_poison logic runs outside the UMM_CRITICAL_* umbrella. When interrupt routines do alloc calls, it is possible to interrupt an in-progress allocation just before the poison is set, with a new alloc request resulting in a false "poison check fail" against the in-progress allocation. The SDK does mallocs from ISRs. SmartConfig can illustrate this issue.
This should resolve #3494 (comment)
Other Sketches built with Debug: "Serial," that use the SDK's Promiscuous callbacks are also likely to encounter problems.
The SDK support for "Promiscuous Receive" allocates memory from an ISR context, occasionally interrupting the poison wrapper code before it finishes setting the poison fences resulting in a false poison failed event.
Edited: expanded description