Open M66B opened 6 years ago
@wanam should I close this issue or does it contain useful info?
I think it's better to keep it open.
Yes, better keep it open. Then once I think I have a solution, you can verify it individually.
Subscribed as i'm suffering from the same issue @rovo89 do you require more logs? (new issue?)
No thanks, I know why this issue occurs. But I need to rethink the whole concept of invalidating possibly outdated method code, which is really not easy.
I'm having the same symptom: got a request to deoptimize un-deoptimizable method. Same environment: Android 8.1, but I'm using Nexus 6 . Sound's like a cause is known, and a solution is tough. Is there anything known about how to work around the cause? What makes a method un-deoptimizable? Is the cause your finding generic to android or is it specific to the use of eu.faircode.xlua packages. I'm not using the eu.faircod.xlua packages. That would at least let me now if my issue is the same related issue.
As guorn23 said if you need any additional logs or other information. I'd be happy to share more details about my situation.
Here's what I found out about my situation. It appears that this error can occur if you don't have the right ClassLoader (whatever right means) In my situation, I am using an OSGI framework and the framework plays tricks with the ClassLoader; so it easily conceivable that in getting an class from an osgi bundle that android thinks the classloader isn't right and gives this warning. It probably doesn't do the optimization phase, but other than that, everything seems to be working fine. So in my case, I think it reasonable to ignore that warning. I'll look to see if there's anything I can do so that those classes can be optimized. When I first saw this message in the application log, it was the last entry before my application hung; making me miss associate that error message with the application hanging. That wasn't the case, I was just making a dumb error of call startActivity when I mean to call startService.
It's hard to explain in a few words. It's not related to a wrong class loader. Deoptimization means that there is compiled code, but it shouldn't be used anymore because the code was compiled under certain assumptions which turned out to be wrong. These assumptions allow for better optimizations, so it's worth to check them at runtime and fall back to the interpreter (and later JIT). In order to deoptimize, certain things about the current execution position, memory registers etc. need to be known.
For those cases that AOSP has, it knows when deoptimization can happen and makes sure to save that information next to the compiled code.
Xposed needs to deoptimize the callers when a method is hooked. This wasn't planned at compile time, so not all required information is available. That's why in the best case, you just see this warning, or in the worst case the app crashes.
I still have to think about better ways. Not deoptimizing is also bad. But alternatives are hard to find.
This should only affect methods which are on the stack when the method is hooked, so hooking methods as early as possible should help. It's also only for compiled code, so resetting the app to interpret-only might help temporarily as well. But there's no real good way to avoid it.
I think that was an excellent explanation with lots of detailed info!
And what about fix? I didn`t find any information how to fix it, HELP :(
Start using edXposed
I I also encountered the same problem in Android8.1.0 @rovo89
@menshen Try EdXposed,it also supports android 8.1.The officical xposed for 8.1 has known bugs and it will always be beta.
Xposed version 90-beta3 on a Nexus 5X with Android 8.1 Oreo
These seem to conflict with each other: https://github.com/M66B/XPrivacyLua/blob/master/app/src/main/java/eu/faircode/xlua/XLua.java#L464 https://github.com/M66B/XPrivacyLua/blob/master/app/src/main/java/eu/faircode/xlua/XLua.java#L817