Use correct recursive mutex for env and regular mutex for tz (IDFGH-9266) #10649
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
github-actions
bot
changed the title
igrr
approved these changes
Jan 30, 2023
|
sha=7ca5fa87c0d6e7173a353425b40293f79838859d |
|
@smjothen thank you for the fix! |
|
@igrr it'll be backported to 4.4, right? |
|
@KaeLL Yes, when it is merged we will also backport it to 4.4 |
3 tasks
This was
linked to
issues
Feb 3, 2023
espressif-bot
added
Status: In Progress
3 tasks
@ESP-Marius Just remind that v4.4 branch still does not include this fix! |
|
@AxelLin it is already merged in our internal gitlab repo. It will be available the next time v4.4 passes QA and syncs to github. |
3 tasks
3 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Newlib defines __env_lock_object as a recursive mutex and __tz_lock_object as a regular mutex, but when initialized in esp_newlib_locks_init, __env_lock_object gets initialized as a regular mutex (points to s_common_mutex) and __tz_lock_object gets initialized to a recursive mutex (s_common_recursive_mutex).
This causes a lot of panics due to various mutex ownership checks in the FreeRTOS code, but only seems to appear when there is a lot of usage of the __tz_lock_object and __env_lock_object. I believe this is also causing the crashes referred to in the issues: #10626 and #9441