From A/looper:could not create epoll instance. errno=24 error talking about the thinking of solving various kinds of bugs

Today the code is written on the inexplicable flash back, the phone does not "program stop running" prompt, Logcat also did not see the blue call stack log, such a flash back most is the egg ache, fortunately must now. After several times, I finally saw a row of suspicious logs from the Logcat: A/Looper: Could not create epoll instance. errno=24 It looked like it was on the native layer again. This article has documented the analytical process of the problem.

Methodology

Met not filled the pit, the first reaction is Google, and sure enough the previous results of a Stack overflow question and answer for this problem to provide a good idea. Of course, the search results do not directly solve the problem, if Google's results can directly solve the problem, I do not need to write such an article, the increase of useless information.

In addition to the ability to directly search the exact same problem, and there is a solution to the situation, there are time only to search for the relevant problems, but there is no solution, or the solution is not work, or simply do not find the relevant information, this time you need to follow the existing information step-by-stage analysis, You can even step into the pit by yourself, usually in several situations:

There is a log, but there is no solution to the search results (often someone who asked the exact same question on stack overflow two years ago, but there is no answer), or the solution is not work. At this point , we can determine where the problem is, based on the information we have searched for . For example, the answer on stack overflow is that it may be that too many files have been opened, and the answer said to have looper.prepare() solved the problem by removing it, it may have created too many lopper . Another example of the log that was encountered in a previous article A/libc: Fatal signal 11 (SIGSEGV) at 0x00000010 (code=1), thread 9302 (RxComputationTh) , the search results are probably caused by multithreaded execution of the native code.

There is a log, but the search does not have meaningful results. Sometimes the search is not the result may be because the search content contains too many local computer-related information, such as file path, many times delete the file path, timestamp and other information, you can search results . If the results are still not found, and log has a more definite meaning, then we can directly analyze the meaning of log, determine the cause of the problem . For example, in another article that was encountered error: 不兼容的类型: java.util.List<java.lang.Object>无法转换为 java.util.List<com.github.piasy.model.entities.GithubUser> , it is certainly irrelevant to take this error message, because it is too short and too common (type conversion error) to remove the classpath of your own definition. However, by analyzing the error message, you can know that the type conversion errors are true. This solves the problem by looking in the code where the type conversions occur in relation to this class.

The worst case scenario is that there is no log, or log doesn't have any useful information. At this point, if the problem is suddenly come out, this time can be through the code difference Analysis to determine the code to introduce the bug, usually the binary search is the most efficient, and git has a very powerful command, git bisect by two points to find commit, To locate the bad commit that introduced the bug. And if there is only one commit, or no version control (what?) ), you can only pull a new branch and locate the bug code by stepping through the comment/delete code.

Well, it's not the worst, and the worst of all is that the situation above is not applicable. This is really no other way, can only be pushed back, in fact, this is still a rollback to locate the bad code type, this shows that the rollback is to locate the bug of the million essential oil, but the efficiency may be the lowest.

A/Looper: Could not create epoll instance. errno=24Incorrect analysis and resolution process

OK back to the specific question, since the judgment may be due to the creation of too many looper caused by the flashback, then look at the code. But my code does not have a place to create a looper! Don't worry, Looper also has a brother Handler,handler is often used to see if handler created too much.

By adding a "non-disruptive" breakpoint to the code that created the handler (without interrupting program execution while debugging, logging only log), it is true that too many handler! are created

OK, find out the possible cause of the problem, change will lead to create too much handler code, test run, the flashback does not appear, OK problem solved satisfactorily:)

From A/looper:could not create epoll instance. errno=24 error talking about the thinking of solving various kinds of bugs