The default bug view has changed. See this FAQ.

remoteautomation.py doesn't set lastTestSeen, so Android crashes fall back to the generic "PROCESS-CRASH | automation.py | application crashed (minidump found)"

RESOLVED FIXED in Firefox 17

Status

Testing
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: emorley, Assigned: emorley)

Tracking

(Blocks: 1 bug)

Trunk
mozilla19
ARM
Android
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox16 wontfix, firefox17 fixed, firefox18 fixed)

Details

(Whiteboard: [sheriff-want])

Attachments

(4 attachments)

Example:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=cb27363cfba1&jobname=Android%20XUL%20Tegra%20250%20mozilla-inbound%20opt%20test%20reftest-2

TBPL only shows:
> PROCESS-CRASH | automation.py | application crashed (minidump found)
> Thread 4 (crashed)

Since the log contains:
{
REFTEST TEST-START | http://10.250.48.212:30104/tests/layout/reftests/font-inflation/threshold-select-combobox-contents-under-2.html | 1607 / 2542 (63%)
INFO | automation.py | Application ran for: 0:04:31.654848
INFO | automation.py | Reading PID log: /tmp/tmp41NaDUpidlog
getting files in '/mnt/sdcard/tests/reftest/profile/minidumps/'
Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/fx-team-android-xul/1337770945/fennec-15.0a1.en-US.android-arm.crashreporter-symbols.zip
PROCESS-CRASH | automation.py | application crashed (minidump found)
}

More useful would be something in the log similar to:
> PROCESS-CRASH | http://10.250.48.212:30104/tests/layout/reftests/font-inflation/threshold-select-combobox-contents-under-2.html | application crashed (minidump found)
Ok, so the "PROCESS-CRASH | automation.py | application crashed (minidump found)" comes from:
http://mxr.mozilla.org/mozilla-central/source/build/automationutils.py#170

...rather than automation.py.in (shows how little I know about the test harnesses lol), so I'm presuming is just the fallback when automation.py has failed miserably to output the crash message with testname.

Either way, having this fixed would make people much more likely to pay attention to Android crashes and actually star them.
Summary: Get automation.py to output current test filename for Android crashes, not just PROCESS-CRASH | automation.py | application crashed (minidump found) → Fix cases where automation.py doesn't output current test filename for Android crashes (and we fall back to automationutils.py's generic "PROCESS-CRASH | automation.py | application crashed (minidump found)")
Whiteboard: [tbpl-want]
Whiteboard: [tbpl-want] → [sheriff-want]
Blocks: 778688
You were close! The testName that gets passed into that method comes from lastTestSeen in automation.py:
http://mxr.mozilla.org/mozilla-central/source/build/automation.py.in#882

I suspect this just isn't implemented in remoteautomation.py.
Yeah:
http://mxr.mozilla.org/mozilla-central/source/build/mobile/remoteautomation.py#79

That doesn't seem to ever get set in remoteautomation.py.
Blocks: 792873
Thank you for the guidance Ted :-)

(Also seems to affect b2gautomation.py)
Blocks: 691425
Summary: Fix cases where automation.py doesn't output current test filename for Android crashes (and we fall back to automationutils.py's generic "PROCESS-CRASH | automation.py | application crashed (minidump found)") → remoteautomation.py doesn't set lastTestSeen, so Android crashes fall back to the generic "PROCESS-CRASH | automation.py | application crashed (minidump found)"
Created attachment 677768 [details] [diff] [review]
Part 1: Cleanup

* Makes waitForFinish()'s parameter names consistent with those in automation.py.in & b2gautomation.py
* Moves the final |print proc.stdout| to RProcess::Wait so it reads more clearly (On my first read through of waitForFinish() I didn't realise we incrementally output stdout in RProcess::Wait as well, so thought that final print was the only print, which changed the required solution somewhat. This hopefully avoids anyone else having the same misunderstanding)
* Other hopefully self-explanatory changes.
Assignee: nobody → bmo
Status: NEW → ASSIGNED
Attachment #677768 - Flags: review?(jmaher)
Created attachment 677790 [details] [diff] [review]
Part 2: Set lastTestSeen

Since the new log content chunks can be fairly large (eg one of the ones I looked at was ~10,000 lines) I also tried a different variation on the regex to see how it compared:
> re1 = re.compile(r".*TEST-START \| ([^\s]*)", re.DOTALL)
> re1.match(newLogContent).group(1)
...but this one was about 7% slower.

Try run (with extra debugging output to confirm correct value of lastTestSeen):
https://tbpl.mozilla.org/?tree=Try&rev=bbc5cf55693a
Attachment #677790 - Flags: review?(jmaher)
Comment on attachment 677768 [details] [diff] [review]
Part 1: Cleanup

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

I would want good try server coverage on this (reftest/mochitest/robocop) before calling this good.  From the changes here, I don't see any big problems.

::: build/mobile/remoteautomation.py
@@ +207,5 @@
>                  if (timer > timeout):
>                      break
>  
> +            # Flush anything added to stdout during the sleep
> +            print self.stdout

self.stdout or proc.stdout?
Attachment #677768 - Flags: review?(jmaher) → review+
> I would want good try server coverage on this (reftest/mochitest/robocop)
> before calling this good.

Yeah agree, will send to try once I have the b2gautomation.py part done :-)

> > +            # Flush anything added to stdout during the sleep
> > +            print self.stdout
> 
> self.stdout or proc.stdout?

The 8 lines of context in this patch unfortunately doesn't show this clearly, but the lines being added are inside RProcess's wait(), so we need self.stdout.
Comment on attachment 677790 [details] [diff] [review]
Part 2: Set lastTestSeen

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

nice!
Attachment #677790 - Flags: review?(jmaher) → review+
Created attachment 677815 [details] [diff] [review]
Part 3: B2G - Cleanup

* Removes didTimeout, since it is never used (carry-over from automation.py.in).
* s/done/responseDueBy/g to make its purpose clearer.
Attachment #677815 - Flags: review?(jgriffin)
Created attachment 677817 [details] [diff] [review]
Part 4: B2G - Set lastTestSeen

Same intent as the part 2 patch, but for b2gautomation.py.
Attachment #677817 - Flags: review?(jgriffin)
Attachment #677815 - Flags: review?(jgriffin) → review+
Attachment #677817 - Flags: review?(jgriffin) → review+
Parts 1+2:
https://tbpl.mozilla.org/?tree=Try&rev=a408c4c481a0

Parts 3+4:
https://tbpl.mozilla.org/?tree=Try&rev=3c195199185b
Landed parts 1+2 for now, to ease the sheriffing pain:
https://hg.mozilla.org/integration/mozilla-inbound/rev/10486f492c02
https://hg.mozilla.org/integration/mozilla-inbound/rev/415dc90118ab
Whiteboard: [sheriff-want] → [sheriff-want][leave open]
https://hg.mozilla.org/mozilla-central/rev/10486f492c02
https://hg.mozilla.org/mozilla-central/rev/415dc90118ab
Flags: in-testsuite-
Parts 3+4:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6486b476e08
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6486b476e08
Whiteboard: [sheriff-want][leave open] → [sheriff-want]
(In reply to Ed Morley [:edmorley UTC+0] from comment #15)
> Parts 3+4:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/b6486b476e08
> https://hg.mozilla.org/integration/mozilla-inbound/rev/b6486b476e08

Second URL should be:
https://hg.mozilla.org/integration/mozilla-inbound/rev/17ce3efb563e
https://hg.mozilla.org/releases/mozilla-aurora/rev/3ca9fbeb5d6f
https://hg.mozilla.org/releases/mozilla-aurora/rev/518d8fac93c4
https://hg.mozilla.org/releases/mozilla-aurora/rev/5b24d43e7ca9
https://hg.mozilla.org/releases/mozilla-aurora/rev/cc464f664272

https://hg.mozilla.org/releases/mozilla-beta/rev/f7736e47130d
https://hg.mozilla.org/releases/mozilla-beta/rev/5c86e35ea6fc
https://hg.mozilla.org/releases/mozilla-beta/rev/d0282d08cb89
https://hg.mozilla.org/releases/mozilla-beta/rev/9de15654e484
status-firefox16: --- → wontfix
status-firefox17: --- → fixed
status-firefox18: --- → fixed
Target Milestone: --- → mozilla19
https://hg.mozilla.org/mozilla-central/rev/b6486b476e08
https://hg.mozilla.org/mozilla-central/rev/17ce3efb563e
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.