TypeError: cannot read property 'threadId' of undefined" about jnitrace HOT 7 CLOSED

Hi, Just to let you know. I have pushed some new features like you suggested. There is now:

-i - to specify method names you want in the output
-e - to specific method names you do not want in the output
-o - to specify an output path to store the data in JSON format.

Hope you find them useful :)

Version 2.0.0 available through pip

from jnitrace.

Thanks for the bug report. Do you mind letting me know what phone you are running on and what app you are using so I can try and reproduce?

from jnitrace.

I think I have found the issue. I have pushed a new version to pip, jnitrace 1.3.3. That should be a temporary fix for the problem. Will start working on a longer term solution. Thanks.

from jnitrace.

@chame1eon Thank you for your hard work, this warning has now been resolved, but unfortunately, the app still crash. As a reference, my phone is nexus6p, os6.0.1, frida 12.6.11, the app can be found here https://github.com/la0s/AndroidQ_SMID/releases

from jnitrace.

No problem. Thanks for the useful feedback.

I think I have gotten to the bottom of the issue. I had the JNI function definitions for GetArrayElement incorrect. I had them returning a primitive type rather than a pointer. When your code used those methods my code was returning incorrect values that caused the crash.

I was able to reproduce this issue as you mentioned and after the changes I made I was able to run jnitrace on the app with no crashes (it did take a long time to run though).

Latest version is available through pip, version 1.3.4. If that fixes your issues, let me know and I can close this issue.

from jnitrace.

👏👏Thanks for fixing the error, now the app can run normally, but the app takes a long time to show, which may be because there are too many JNI apis to trace, so I think it is possible to follow the function of custom tracing, such as ExceptionOccurred, DeleteGlobalRef that we are not interested 😁

from jnitrace.

No problem. I am going to close the issue as the bug is fixed. I agree with you on the filtering the JNI API calls. I am working on a feature update to do that 😀

from jnitrace.