Skip to content
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

inline.extended.ExtendedMockito.mock() sporadically fails on com_android_dx_mockito_inline::InspectClass #134

Closed
ttanxu opened this issue Jan 23, 2019 · 0 comments

Comments

@ttanxu
Copy link
Contributor

ttanxu commented Jan 23, 2019

In a multi-thread situation there could be native crashes around mocking of static methods (issue #97), even though client doesn't write any native code.

Thread A is running Java_com_android_dx_mockito_inline_StaticMockMethodAdvice_nativeGetCalledClassName() in staticjvmtiagent/agent.cc.
Thread B is the crashing thread that is calling file loaded callbacks to handle classes retransformation, due to an explicit call into Java_com_android_dx_mockito_inline_JvmtiAgent_nativeRetransformClasses() in dexmakerjvmtiagent/agent.cc.

Sequence of events:
(Thread A) Registers file loaded callback using jvmtiEnv->SetEventCallbacks()
(Thread B) JVMTI collects event handler in CollectEvents(), called by DispatchClassFileLoadHookEvent() in events_inl.h
(Thread A) Disposes environment using jvmtiEnv->DisposeEnvironment()
(Thread B) JVMTI into the callback set in Thread A with a disposed jvmtiEnv, and crash.

ttanxu added a commit to ttanxu/dexmaker that referenced this issue Jan 23, 2019
If there are other threads asking for class restransformation
InspectClass may be called during the transient period of time when the
callback is enabled. More importantly InspectClass could be called after
jvmti env is disposed, which would lead to native crashes.

This should fix issue linkedin#134.
ttanxu added a commit to ttanxu/dexmaker that referenced this issue Jan 24, 2019
If there are other threads asking for class restransformation
InspectClass may be called during the transient period of time when the
callback is enabled. More importantly InspectClass could be called after
jvmti env is disposed, which would lead to native crashes.

This should fix issue linkedin#134.

Also change .travis.yml to accept new license for NDK.
drewhannay pushed a commit that referenced this issue Jan 24, 2019
If there are other threads asking for class restransformation
InspectClass may be called during the transient period of time when the
callback is enabled. More importantly InspectClass could be called after
jvmti env is disposed, which would lead to native crashes.

This should fix issue #134.

Also change .travis.yml to accept new license for NDK.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants