Appium server shutting down if element is not found on page in Windows environment

[Amit Dewan]

Hi,

I have started encountering an issue with the Appium server running on my Windows machine. I have created a suite of test cases for my android native app. I run the Appium server(ver-13.0) from the Appium.exe on my Windows7 machine. After providing all valid entries for my android native app in the Appium server GUI, I then run the test cases batch.

Issue: If the declared elements are displayed, the complete batch executes successfully, as expected and the Appium server continue to stay up, which is great. However, if during the execution any of the declared element is not identified(or fails to be identified by the driver), the script fails resulting in shutting down of Appium server. As a result of this the remaining scripts fails to execute since the Appium server goes down on encountering a test failure during execution of the script.

What's Working: I have a similar setup on my mac machine for the same android native app. But when I run this batch of test cases on my android native app from my Mac(OSX 10.9), the Appium server continues to stay alive, even after encountering a similar script failure of not being able to identify the declared element.

Is this an expected behavior of Appium server on Windows machine? If yes, could you please suggest a possible workaround to keep the Appium server up even when a script fails?

Please provide a solution to this issue.

Thanks in advance...

[Jonathan Lipps]

Are you saying appium crashes when an element is not found? That shouldn't happen. Please provide the appium log so we can see what's wrong.

But first, try appium 0.15.0, it's quite a bit newer and the issue might already be fixed.

--
http://appium.io
---
You received this message because you are subscribed to the Google Groups "Appium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appium-discus...@googlegroups.com.
Visit this group at http://groups.google.com/group/appium-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

[Amit Dewan]

Hi Jonathan,

Thanks for the quick reply. Based on your feedback I switched to the latest Appium(ver 15) and now I'm observing the following behavior, while running the batch for my Android native app from my windows7 machine:

Observation1: Now, when I run the Appium server with the 'Perform Full Reset' button checked in the GUI, and if then the driver fails to identify an element in the test app during test run, the Appium server continues to run without any issues. Further my test batch gets executed successfully, but then it takes lot of time.

Observation2: However, if I run the Appium server with the 'Perform Full Reset' button unchecked in the GUI, and if one of the test script fails, the Appium server shuts down, on failing to find an element, which is strange.

Also, for your reference, I'm attaching the appium server logs for Observation2 above.

Please look into this issue.

Thanks in advance...

[Jonathan Lipps]

The problem is that when an element is not found, your test framework tries to take a screenshot of the device state. That is failing and causing appium to crash.

Here's the command that crashes uiautomator:

"E:\ADT_Plugin\adt-bundle-windows-x86_64-20130522\adt-bundle-windows-x86_64-20130522\sdk\platform-tools\adb.exe" -s 0582d11d shell "/system/bin/rm /data/local/tmp/screenshot.png; /system/bin/screencap -p /data/local/tmp/screenshot.png "

@bootstraponline, I thought screenshots crashing uiautomator was a known issue and something we can recover from?

Amit, can you run that command by hand and see if anything else interesting happens?

<appium_server_logs.txt>

[bootstrap online]

I looked at the log. The problem is adb becomes null which crashes appium.

"this.adb.pull('/data/local/tmp/screenshot.png', localfile, cb);"

The code isn't written to expect that adb randomly becomes null.
/system/bin/screencap is just a binary on the system unrelated to
uiautomator so it shouldn't be causing problems.

[Jonathan Lipps]

OK, what I'm confused about then is why we have one part of the screenshot flow in the log above the shutdown command, and then an error from the next part of the screencap flow after the shutdown. That's what made me think the first screencap command was causing a shutdown. But you're right--on closer inspection it looks like we're actually sending the shutdown command. So why are we doing that in the middle of the screencap flow?

[bootstrap online]

> So why are we doing that in the middle of the screencap flow?

I don't know. Somehow the screencap and shutdown are running in
parallel. The screencap request should block the shutdown command from
being executed until the screenshot logic is complete.

[Jonathan Lipps]

I just added a logline so we can try to follow the execution a bit better. If you're not running from master I think we'll have to wait for the next release to see what's happening here.

-Jonathan