[core] Deadlock #743
Comments
|
Without a detailed analysis I would assume that this dead lock may occur in case we have to classes A and B that (indirectly) references the other class. In case one thread_1 starts with class A and thread_2 starts with class B we are 100% sure to run into a dead lock. I assume the main problem is here in Therefore we are effectively executing (pseudocode): My suggest would be to split class processing and code generation for multi-threaded processing: The code above bases on the assumption that we don't have a full class list that includes outer and inner classes - our class list only contains outer classes that are visible in the class tree. My proposed changes are therefore:
|
|
@jpstotz thanks for suggestions, but in this case, the main cause was calling class process from another class process, look at at jadx.core.ProcessClass.process(ProcessClass.java:35)
- waiting to lock <0x0000000444a58f28> (a jadx.core.dex.info.ClassInfo)
at jadx.core.dex.nodes.ClassNode.loadAndProcess(ClassNode.java:251)
at jadx.core.dex.nodes.RootNode.getClassGenerics(RootNode.java:279)
at jadx.core.utils.TypeUtils.replaceClassGenerics(TypeUtils.java:35)
at jadx.core.dex.visitors.typeinference.TypeUpdate.invokeListener(TypeUpdate.java:296)
...
at jadx.core.dex.visitors.DepthTraversal.visit(DepthTraversal.java:14)
at jadx.core.ProcessClass.process(ProcessClass.java:43)
- locked <0x0000000444a53c20> (a jadx.core.dex.info.ClassInfo)I was using the method Also, I want to make some additions to your analysis to make sure we are on the same page:
And FYI I have a lot of plans on how to optimize class processing:
Hope this will clear up some code designs and current problems in jadx :) |
|
@skylot OK collecting the dependency information and building a dependency graph is also nice. Do you already have a working partitioning algorithm in mind for splitting up the graphs in regions that don't "collide", one for each thread? Or do you have an alternative approach in mind how to make use of the dependency information? |
|
@jpstotz actually no, sorry. |
|
@skylot Furthermore the main problem you are running into is that you have no tree. If the classes would always build a tree, our current algorithm would work well without dead locks. To cover all cases may be the simplest algorithm is to check the dependency graph for classes that only have incoming edges (using the edge definition A -> B "class A depends on class B" - that would the leaves you were talking about). |
|
@jpstotz, of course, I know that this is a graph with cycles, but cycles are so rare, and multi-root is also possible but not with hundreds of classes. So I mean "most common" shape of this graph. And by "dynamic management" I mean that we can And as a conclusion: main problems of deadlock is not "how" code must work but that it is easy to make mistake (break assumptions) and hard to write a tests for these multithreaded problems :( |
|
Thanks @skylot! Works perfect now |
Hi @skylot,
I've noticed that a lot of apps are not decompiled completely. I caught one of them with a deadlock
jadx-cli args
Output of
jstackAPK: https://drive.google.com/file/d/18wPwqqSeeppz5LDybFX3CLvAZJ3sB7JJ/view?usp=sharing
The text was updated successfully, but these errors were encountered: