Ensure we never instrument Proxy.<init> entrypoint
Due to the way we implement Proxy classes we need to be very careful
when modifying proxy classes and the (non-proxy)
java.lang.reflect.Proxy class and its methods. In particular we always
avoid installing an instrumentation entrypoint into the Proxy.<init>
method since we copy it for each proxy class. Failing to do this
causes problems as the instrumentation entrypoint bounces to the Proxy
entrypoint which gets confused since the copied init method is not
really a proxy method. Unfortunately if one starts the profiling
process early enough it was possible for the Proxy.<init> method to
get instrumented as it is being loaded. This CL ensures that the
method is skipped just like it would be if profiling was started
later.
NB Test requires several other patches to actually run far enough to
observe this issue.
Test: ./test/testrunner/testrunner.py --host --runtime-option=-Xplugin:libtracefast-trampolined.so
Test: ./test/testrunner/testrunner.py --host --run-test-option='--with-agent libtifast.so=MethodEntry,MethodExit'
Change-Id: I18fb381d18d7100b5ec843b3cddd387f2d033776
diff --git a/runtime/class_linker.cc b/runtime/class_linker.cc
index 1710e78..c374e03 100644
--- a/runtime/class_linker.cc
+++ b/runtime/class_linker.cc
@@ -4440,8 +4440,8 @@
// Find the <init>(InvocationHandler)V method. The exact method offset varies depending
// on which front-end compiler was used to build the libcore DEX files.
- ArtMethod* proxy_constructor = proxy_class->FindConstructor(
- "(Ljava/lang/reflect/InvocationHandler;)V", image_pointer_size_);
+ ArtMethod* proxy_constructor =
+ jni::DecodeArtMethod(WellKnownClasses::java_lang_reflect_Proxy_init);
DCHECK(proxy_constructor != nullptr)
<< "Could not find <init> method in java.lang.reflect.Proxy";