-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Fix race condition in ReadableNativeMap #36201
Conversation
This pull request was exported from Phabricator. Differential Revision: D43398416 |
|
Base commit: ed8a3e0 |
Summary: Pull Request resolved: facebook#36201 [Changelog][Internal] Guard call to the C++ ReadableNAtiveMap.importValues with a lock. Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136. My corresponding comment from the task, for justification: > If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues(). It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions. > Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't. NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well. Reviewed By: javache Differential Revision: D43398416 fbshipit-source-id: 642a7d6b9e38ea7ee303c113a66f6a5c5fa38cdd
This pull request was exported from Phabricator. Differential Revision: D43398416 |
7948343
to
032ceb1
Compare
This pull request has been merged in 9aac13d. |
Summary: Pull Request resolved: #36201 [Changelog][Internal] Guard call to the C++ ReadableNAtiveMap.importValues with a lock. Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136. My corresponding comment from the task, for justification: > If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues(). It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions. > Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't. NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well. Reviewed By: javache Differential Revision: D43398416 fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary: Pull Request resolved: facebook#36201 [Changelog][Internal] Guard call to the C++ ReadableNAtiveMap.importValues with a lock. Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136. My corresponding comment from the task, for justification: > If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues(). It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions. > Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't. NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well. Reviewed By: javache Differential Revision: D43398416 fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340 (cherry picked from commit 0d3c70b)
Summary: Pull Request resolved: facebook#36201 [Changelog][Internal] Guard call to the C++ ReadableNAtiveMap.importValues with a lock. Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136. My corresponding comment from the task, for justification: > If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues(). It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions. > Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't. NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well. Reviewed By: javache Differential Revision: D43398416 fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary:
[Changelog][Internal]
Guard call to the C++ ReadableNAtiveMap.importValues with a lock.
Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136.
My corresponding comment from the task, for justification:
NOTE: A couple of
importKeys()
instances appears to suffer from the same problem as well.Reviewed By: javache
Differential Revision: D43398416