Closed xWTF closed 5 months ago
This is not correct. When class_def is not present, this is specially for async entrypoint setting, which is done in batch. When class_def is present, it will only restore backup for that class, but it does not mean all classes in this thread are done setting entrypoint.
If you change it to nullptr
, it may cause a race condition.
I see, thanks for your correction.
Further testing reveals that the same code (with mirror_class->GetClassDef()
called) does NOT cause SIGSEGV:
user
builduser
/ userdebug
build (everything else is the same except for the sysdir)eng
build, however the PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD
was set to false in order to use non-debug libart (libart.so)PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD
in the previous build, switching back to the debug target of libart (libartd.so)For anyone who comes from search in the future, you can either switch to a userdebug
or user
build or set PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD := false
in your mk files to prevent the selection of the debug variant and still get most benefits from eng
builds.
I assume there must be something wrong within these if
s, however it's already taking like 10 hours to troubleshoot this segfault, so I'm not planning to go ahead.
BTW sorry for the midnight reply, the AOSP build cycles really take a lot of time to do, especially when I switch to another variant which disables the incremental build.
Problem
In class_linker.hpp, the call from
FixupStaticTrampolines(Thread* self, ObjPtr<mirror::Class> klass)
toRestoreBackup
passes bothmirror_class->GetClassDef()
andself
parameter.Tracing down to the
mirror::Class::PopBackup
function, it's obvious that whenclass_def
presents,self
parameter is not used:https://github.com/LSPosed/LSPlant/blob/2cccfae8c1ecaee5592c7a89b5ac1c9692fe76c3/lsplant/src/main/jni/art/mirror/class.hpp#L160-L182
Fix
I just replaced
mirror_class->GetClassDef()
withnullptr
, please correct me if it violates the desired behaviour.Sidenote
The call to
GetClassDef
is causing a mysteriousSIGSEGV
in my AOSP 14 R29 x86_64 emulator (GrapheneOS 2024032100), the exact cause is still unknown after many hours of debugging, therefore I decided to take a look at LSP source and discovered this.Removing the call to restore all backed up methods in current thread appears to be a practical way to avoid the crash and everything else worked perfectly. Any help in troubleshooting this SIGSEGV is appreciated. Here's the crash log snippet I just reproduced on a fresh build of GrapheneOS 2024040300 emulator: