-
Notifications
You must be signed in to change notification settings - Fork 3k
Added missing _mutex->unlock() to FileBase::lookup(). #8451
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
I understood the ScopedLock would be a better way to fix this. If we go with the better fix, please feel free to close this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do recall seeing this error during development of #7924.
I corrected it by changing to ScopedLock<PlatformMutex>
, but when that was rejected during review, I dropped the commit, forgetting that the commit was actually fixing this mutex bug, not just a style adjustment. Whoops.
You could switch to ScopedLock
again, but this is okay.
I think we've not seen a problem because it's a recursive mutex, so wouldn't show any issues until you've got two threads doing file opening (with at least one using /default
.)
👍 |
/morph build |
Build : FAILUREBuild number : 3380 |
IAR network license issues. |
Build : SUCCESSBuild number : 3387 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 3019 |
Test : SUCCESSBuild number : 3189 |
Description
My modified Pelion Device Management Client has been getting stuck in the startup for a while now. After days of debugging, I finally was able to pinpoint the system to a mutex deadlock.
I don't thought understand how this has worked with the already released PDMC.
Pull request type
@kjbracey-arm, related to the discussion on the hallway, this fix is related to previous modification done in here #7924