Closed Bug 1084519 Opened 5 years ago Closed 5 years ago

devicemanagerADB.getInfo("uptime") fails on some devices

Categories

(Testing :: Mozbase, defect)

x86_64
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla36

People

(Reporter: gbrown, Assigned: davehunt)

References

Details

Attachments

(1 file)

"uptime" on my newly-booted device returns an unexpected format, which causes an error in devicemanagerADB.getInfo().

$ make mochitest-robocop
Traceback (most recent call last):
  File "_tests/testing/mochitest/runtestsremote.py", line 822, in <module>
    sys.exit(main(sys.argv[1:]))
  File "_tests/testing/mochitest/runtestsremote.py", line 643, in main
    mochitest.printDeviceInfo()
  File "_tests/testing/mochitest/runtestsremote.py", line 532, in printDeviceInfo
    self.log.info("Device info: %s" % self._dm.getInfo())
  File "/home/gbrown/objdirs/droid/_tests/testing/mochitest/devicemanagerADB.py", line 512, in getInfo
    [int(g or 0) for g in m.groups()[1:]])
AttributeError: 'NoneType' object has no attribute 'groups'
make: *** [mochitest-robocop] Error 1

$ adb shell uptime
 18:07:30 up 2 min,  0 users,  load average: 0.16, 0.20, 0.08

Regression from bug 1081167?
(In reply to Geoff Brown [:gbrown] from comment #0)
> Regression from bug 1081167?

That would seem likely - sorry! Your uptime looks a lot different from mine:

$ adb shell uptime
up time: 1 days, 04:55:38, idle time: 21:36:40, sleep time: 17:42:29

I can't see your uptime fitting into the expectations of DeviceManagerADB even before my change though. What value did you get before the regression was introduced?
If I back out bug 1081167, robocop tests run to completion. Curiously, the test harness calls getInfo with directive = None and the old code returns {}!

If I manually getInfo("uptime") with the old code and my device (Android 4.0.1) now reports:

 19:32:16 up  1:27,  0 users,  load average: 0.00, 0.03, 0.04

getInfo returns:

{'uptime': ['0 days  up  1 hours 27,  0 users,  load average minutes  0.00 seconds']}
It would be worth trying to extract the relevant details from the various different uptime strings, but this will fallback to the entire string if the result cannot be parsed. This will prevent the AssertionError and give a slightly more useful uptime value.
Assignee: nobody → dave.hunt
Status: NEW → ASSIGNED
Attachment #8507828 - Flags: review?(gbrown)
Comment on attachment 8507828 [details] [diff] [review]
Return full uptime string if regex fails. v1.0

Review of attachment 8507828 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks Dave. 

That works for me and I like your approach. I don't see any point in getting more complicated -- we could chase after other uptime formats without adding much value.
Attachment #8507828 - Flags: review?(gbrown) → review+
https://hg.mozilla.org/mozilla-central/rev/75e8a2121a08
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
mozdevice 0.43 has been released with this fix.
You need to log in before you can comment on or make changes to this bug.