Under what circumstances would frida-server cause 100% CPU usage and become unresponsive?

[lanyuer]

I started a frida-server, connected to it remotely, attached a process, and executed a script to call functions within the process. After running for some time, the frida-server becomes unresponsive. On my Pixel 4 phone, I noticed that the CPU is being exhausted, mainly by one process: unix:abstract=/frida-f4feb1bd-3f32-4282-bd which occupies 99.6% of the CPU.

I use strace to trace this process and sees that it keeps calling this piece of code: ppoll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}], 2, {tv_sec=0, tv_nsec=142951995325120880}, NULL, 0) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {tv_sec=2278038456091393255, tv_nsec=4088476032}) = 0 ptrace(PTRACE_DETACH, 1452, NULL, SIG_0) = -1 ESRCH (No such process) ptrace(PTRACE_INTERRUPT, 1452) = -1 ESRCH (No such process) ppoll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}], 2, {tv_sec=0, tv_nsec=142951995325120880}, NULL, 0) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {tv_sec=2278596286443797735, tv_nsec=4088476032}) = 0 ptrace(PTRACE_DETACH, 1452, NULL, SIG_0) = -1 ESRCH (No such process) ptrace(PTRACE_INTERRUPT, 1452) = -1 ESRCH (No such process) ppoll([{fd=3, events=POLLIN}, {fd=13, events=POLLIN}], 2, {tv_sec=0, tv_nsec=142951995325120880}, NULL, 0) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {tv_sec=2279108590142864615, tv_nsec=4088476032}) = 0 ptrace(PTRACE_DETACH, 1452, NULL, SIG_0) = -1 ESRCH (No such^C{tv_sec=2295757257771695335, tv_nsec=4088476032}) = 0 ptrace(PTRACE_DETACH, 1452, NULL, SIG_0strace: Process 28541 detached

The problem is that this process of 1452 no longer exists. Is there something wrong with the way I am using it?

[asafe199]

I've been handling the same issue here, I have a routine which runs my script for all day long. However, I noticed that even closing frida "adb shell kill -9 {PID}" for each routine there are process in background

[ricsirigu]

same issue here, with Frida 16.1.11 and 16.2.1. After a while the phone crashes.

[ptraced]

@oleavr how's this still not fixed