-
-
Notifications
You must be signed in to change notification settings - Fork 16
Fix crash-causing pthread race condition & rework pthread implementation #47
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
Open
V3L0C1T13S
wants to merge
7
commits into
minecraft-linux:master
Choose a base branch
from
V3L0C1T13S:rework-pthreads
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
bb032b9
Fix crash-causing pthread race condition & rework pthread implementation
V3L0C1T13S f1505e0
fix pthread_mutex_t 32-bit ABI compat
V3L0C1T13S ed09a0d
restore 32-bit ABI compat
V3L0C1T13S 499996a
fix: force pthread_mutex_t to have proper alignment regardless of pla…
V3L0C1T13S 214f3c0
(hopefully) fix pthread_mutex_t on OSX
V3L0C1T13S f067f26
more accurately handle use of destroyed mutex
V3L0C1T13S b3771ab
add guard for nullptr mutex on 32-bit ABI
V3L0C1T13S File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
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.
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.
Somehow this tells me, we have 4bytes
https://android.googlesource.com/platform/bionic/+/master/libc/bionic/pthread_mutex.cpp#247
Uh oh!
There was an error while loading. Please reload this page.
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.
Ah, I see now... You're definitely correct, yes. I'll need to store just an ID for the mutex like how Bionic does it, then have a mapping of ID to internal mutex info? I don't see how else I can get around the 4 byte size limitation.
Uh oh!
There was an error while loading. Please reload this page.
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.
Newest changes should restore 32-bit compat. The 32-bit ABI does not benefit from the race condition fix, but it should work as it did before. I was able to test this time around by using the 32-bit pthread_mutex_t structure on a 64-bit build, which surprisingly did work, MCPE doesn't seem to rely on the structure's size.
Is there a reason why we're accurate to Bionic so deeply in the first place if apps aren't actually dependent on the ABI level size?
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.
having a smaller mutex is fine for me, but if our layout is larger than bionic we have write after free, altering following fields errors etc.
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.
Makes sense to me, then.