Whether I use this:
process = Runtime.getRuntime().exec("logcat -d time");
or that:
process = new ProcessBuilder()
.command("logcat", "-d", "time")
.redirectErrorStream(true)
.start();
I get the same results: it often hangs within the exec() or start() call, no matter what I tried to do!
The thread running this cannot even be interrupted with Thread.interrupt()! The child process is definitely started and if killed the above commands return.
These calls may fail on first attempt, so THERE IS NO WAY TO READ THEIR OUTPUT! I can also use a simple "su -c kill xxx" command line, same result!
EDIT: Started debugging the java_lang_ProcessManager.cpp file in an NDK project with some debugging logs! So here is what I found so far, after the fork() the parent does this:
int result;
int count = read(statusIn, &result, sizeof(int)); <- hangs there
close(statusIn);
Though the child process is not supposed to block on it: That's what the child does (if started at all!):
// Make statusOut automatically close if execvp() succeeds.
fcntl(statusOut, F_SETFD, FD_CLOEXEC); <- make the parent will not block
// Close remaining unwanted open fds.
closeNonStandardFds(statusOut, androidSystemPropertiesFd); <- hangs here sometimes
...
execvp(commands[0], commands);
// If we got here, execvp() failed or the working dir was invalid.
execFailed:
int error = errno;
write(statusOut, &error, sizeof(int));
close(statusOut);
exit(error);
The child can fail for 2 reproducible reasons:
1- child code is not running, but the parent believes it is!
2- child blocks on
closeNonStandardFds(statusOut, androidSystemPropertiesFd);
In either case the read(statusIn...) in the parent ends in deadlock! and a child process is left dead (and cannot be accessed, pid unknown, no Process object)!
This problem is fixed in Jelly Bean (Android 4.1) but not in ICS (4.0.4) and I guess it will never be fixed in ICS.
Above solution didn't prove to be reliable in any ways, causing more issues on some devices!
So I reverted back to the standard .exec() and kept digging...
Looking at the child code that hangs, I noticed the child process will hang while trying to close all file descriptors inherited from the parent (except the one created within the exec() call) !
So I search the whole app code for any BufferedReader/Writer and similar classes to make sure those would be closed when calling exec()!
The frequency of the issue was considerably reduced, and actually never occured again when I removed the last opened file descriptor before calling exec().
NB: Make sure SU binary is up-to-date, it can actually cause this issue too!
Enjoy your search ;)
Bug fix in Bionic was commited monthes ago, but it still hasn't been included in Android 4.0.4.
I have the same problem on ICS (seem to works fine on Android < 4). Did you find a solution?
A simple workaround could be to call the "exec" method in a dedicated thread with a timeout-join so that this situation could be "detected" (yes I know it's not very elegant...)
Related
I have a library written in C that I'm using from an Android application. I discovered that the application blocks sometimes while executing various functions (what is common is they are all related to networking).
I'm testing on a real Android device running Android 6.
The library is compiled with NDK version 21.
So far I have observed this behavior with 3 functions - getaddrinfo, poll and socket:
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
getaddrinfo(hostname, port, &hints, &result);
////
struct pollfd wait = {
.fd = fd,
.events = event,
.revents = 0
};
status = poll(&wait, 1, 10000);
////
fd = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
These functions are called several times each after the program starts running. The same call can work fine one time and block indefinitely (at least several minutes) the next time. The internet connection on the device seems to be fine.
Any ideas? How can I even approach debugging such a problem?
I didn't actually find the reason for the problem, but I found how to fix it. Part of the code was written by somebody else and I wasn't sure what exactly it was doing. After rewriting this part, everything started to work fine.
Among other things, the code was spawning a new process with fork(). I suspect the problem to be related to that.
As we all know android doesn't unload *.so after close application. I had found the solve by adding "exit(0)" at the end, that is solved problem, but I wanna know exactly that all are OK.
The code is work fine as expected after solving the problem:
static int value = 0;
// In android_main
LOGI("value = %d", value); // always print 0, but not 1 after second run of
// application as it was without "exit(0)" at the end
value = 1;
I wanna to test that on class like:
class A {
A() {
LOGI("Constructor");
}
~A() {
LOGI("Destructor");
}
statis A a;
In such way prints only "Constructor".
Maybe because of destructor is calling after when LOGI isn't working more for application that will be closed ?
Question: why LOGI in destructor isn't working? According to first example on top destructor is calling really.
This is not only pointless, but quite possibly counterproductive. If android wants the memory utilized by your process, it will terminate the process to reclaim it; if it doesn't, it won't.
To specifically address your question, killing or exiting a process does not invoke destructors, it merely terminates execution and the kernel bulk-releases all memory and (conventional) resources.
Do not try to second guess the system, as that can frequently result in killing a process only to have android immediately restart it. Further, it can allegedly cause problems with a few Android IPC resources (like the camera) which may not be freed up when the process of a utilizing application unexpectedly dies.
I'm trying to test my android application with appium and I'm looking for a solution to the following issue:
In my application I have a section that takes time (for image processing) and it sometimes can take one minute, two minute or even more depends on the image size, quality.
In my test case I'm trying to wait for lets say 30 seconds and then I'm checking if the image processing is done.
The problem is if I'm waiting too long, I got the next message:
info: [debug] Didn't get a new command in 60 secs, shutting down...
I don't want to set a 'newCommandTimeout' cause I want to cut the test time and I want to test check if its done every short period.
In addition, I can't use the wait for element or something like that of appium API because I'm using a third party library which tells me when the image processing is done.
My questions is, there is any way to send a 'fake' command to appium so every 30 seconds that my thread is back to work and if I see that the image processing is not done I'll send a fake command and then go back to sleep for 30 seconds without any worry that the appium server will be shut down due to timeout?
Not sure what you are using for wait command. Use this:
WebDriverWait wait = new WebDriverWait(driver, 10);
wait.until(ExpectedConditions.visibilityOfElementLocated(locator));
This will wait until it finds the element on screen.
In addition to the comment here:
In order to solve this issue I use the WebDriverWait with a custom ExpectedCondition and it looks like:
new WebDriverWait(mDriver, 30) // 30 is for the time out
.withMessage("You can set any custom error message")
.until(new ExpectedCondition<Boolean>() {
#Override
public Boolean apply(WebDriver d) {
//This function will be called repeatedly until
//the return value will be true
}
});
You can see other implementations of WebDriverWait and actually I think it works with any Object instead of Boolean.
I have a problem setting up Robotium tests to run on Travis without random false posivities.
Every couple of builds I get
pl.mg6.agrtt.TestActivityTests > testCanEnterTextAndPressButton[test(AVD) - 4.4.2] FAILED
junit.framework.AssertionFailedError: EditText is not found!
at com.robotium.solo.Waiter.waitForAndGetView(Waiter.java:540)
on all my tests.
I have created a simple project on GitHub to show the issue.
You may see how it builds on Travis. Note build #7 failed after modyfing unrelated file.
I'm suspecting this to be caused by emulator being locked or its sceeen dimmed. I could reproduce this issue on local machine by turning connected device's screen off and then running
./gradlew connectedAndroidTest
After modyfing tests I got a different error message, which is somewhat more informative, so I'm adding it just in case someone tries to find a solution:
pl.mg6.agrtt.TestActivityTests > testCanFindViewsEnterTextAndPressButton[test(AVD) - 4.4.2] FAILED
junit.framework.AssertionFailedError: Click at (160.0, 264.0) can not be completed! (java.lang.SecurityException: Injecting to another application requires INJECT_EVENTS permission)
at com.robotium.solo.Clicker.clickOnScreen(Clicker.java:106)
While the root cause of this problem is still unknown to me, after some investigation and with a help from Robotium's author Renas Reda I could confirm what I initially suspected that emulator indeed locks itself.
A workaround I'm using now is this code put in setUp method:
getInstrumentation().runOnMainSync(new Runnable() {
#Override
public void run() {
getActivity().getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD);
}
});
Robotium discards invisible views when using enterText(int, String). Instead use getView(int) of Solo to use resulting view in enterText(View, String).
Like this:
public void testCanEnterTextAndPressButton() {
solo.enterText(((EditText) solo.getView(R.id.editText1)), "my login");
solo.enterText(((EditText) solo.getView(R.id.editText2)), "my password");
solo.clickOnView(solo.getView(R.id.button));
}
And if the device screen is locked Robotium fails to run those instructions you gave. You might want to disable screen locking.
By code above my tests pass.
Your guess is probably right. One way to be sure that it is is to catch the exception that is thrown and call
solo.takeScreenshot("screenshotFileName");
and then take a look at the screenshot that is saved to your phone's SD card to see what your phone was doing at the time of the error.
I solved this problem by turning on the device's "Stay Awake" setting so it won't sleep while recharging.
In Eclipse, I notice that Logcat only retains a few dozen entries and deletes the older ones as soon as a new one come in. Is there a way to prevent this? I need my app to run for a long time and not lose any entries because my app eventually hangs or crashes after a few days, and I want to see if something in Logcat has been recorded.
I am not sure if this is the most elegant solution to the problem, but you can always increase the LogCat message size in Eclipse.
Window -> Preferences -> Android -> LogCat -> Maximum number of LogCat messages to buffer
The default is 5000, I believe. You can set it to be very high if you are planning to run your application for a long time.
i think you need to increase this show image
Here's a better solution:
Set the Default Uncaught Exception Handler. Whenever the app crashes, this will be called with the exception. Simply write a log entry saying it crashed then dump the logcat to a file. Finally, make sure you re-throw the exception to make sure the app crashes and funky things don't happen. Note: This is per thread, keep that in mind.
Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable ex) {
Log.e("TAG", "---My app crashed just now---", ex);
//TODO: Dump logcat to file
throw new RuntimeException(ex);
}
});
if you want to keep your app running for days.. its better you capture your logs from adb shell.
the common shell command would be :
logcat -c \\ to clear previous logs
logcat -v time>yourLogs.txt & \\ to capture fresh logs