If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Running mochitest-robotium locally always fails with Automation Error: No crash directory

RESOLVED FIXED in mozilla23

Status

Testing
Mochitest
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: nalexander, Assigned: nalexander)

Tracking

unspecified
mozilla23
All
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

5 years ago
This leads to `make: *** [mochitest-robotium] Error 1` which makes me sad.

A little hunting shows that

Automation Error: No crash directory (/mnt/sdcard/tests/profile/minidumps/) found on remote device

is only thrown from http://mxr.mozilla.org/mozilla-central/source/build/mobile/remoteautomation.py#131

Comments in the utilities suggest that the profile/minidumps directory is usually created by Fennec at startup, but since I am building with --disable-crashreporter presumably this doesn't happen.  Can we weaken this condition, or add a flag to ignore it, or wire in checking for crash reporter, or...
(Assignee)

Comment 1

5 years ago
Bug 724110 is related, in that the desired behaviour would need to be gated on whether crash reporting is enabled.
See Also: → bug 724110
If you look at the comments in the code that was linked in the original bug report (http://mxr.mozilla.org/mozilla-central/source/build/mobile/remoteautomation.py#131), this is assumed that fennec always creates that.  To me that looks like we did the right thing, now there is a new case, and we should handle that, not lay blame on the original code.

Is there a way to detect at runtime if the crashreporter is enabled?  This code is harness code which lives outside of the browser, maybe we just remove our assumption that it is created all the time.
If you can get the mozinfo.json from the objdir (we package it with the xpcshell tests) that has a key that indicates whether the crashreporter is built or not.
(Assignee)

Comment 4

5 years ago
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> If you can get the mozinfo.json from the objdir (we package it with the
> xpcshell tests) that has a key that indicates whether the crashreporter is
> built or not.

This would do nicely.
(Assignee)

Comment 5

5 years ago
Created attachment 739665 [details] [diff] [review]
Patch against m-i

This turned out to be easier than expected -- `automation.py.in` already has a CRASHREPORTER member.  But the field seems bitrotted: it was

#expand _CRASHREPORTER = __CRASHREPORTER__ == 1

(http://dxr.mozilla.org/mozilla-central/build/automation.py.in#l55) and mxr says that __CRASHREPORTER__ is not referenced anywhere else in the tree.  In fact, none of these double-underscore expansions appear elsewhere in the tree, but I only audited the handful of code paths around CRASHREPORTER.
Assignee: nobody → nalexander
Attachment #739665 - Flags: review?(jmaher)
Comment on attachment 739665 [details] [diff] [review]
Patch against m-i

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

lets fix the crsahreporter definition, otherwise this looks great.

::: build/automation.py.in
@@ +70,5 @@
>  #expand _DEFAULT_APP = "./" + __BROWSER_PATH__
>  #expand _CERTS_SRC_DIR = __CERTS_SRC_DIR__
>  #expand _IS_TEST_BUILD = __IS_TEST_BUILD__
>  #expand _IS_DEBUG_BUILD = __IS_DEBUG_BUILD__
> +#expand _CRASHREPORTER = MOZ_CRASHREPORTER == 1

__CRASHREPORTER__ is expanded here:
http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py#356
Attachment #739665 - Flags: review?(jmaher) → review-
(Assignee)

Comment 7

5 years ago
(In reply to Joel Maher (:jmaher) from comment #6)
> Comment on attachment 739665 [details] [diff] [review]
> Patch against m-i
> 
> Review of attachment 739665 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> lets fix the crsahreporter definition, otherwise this looks great.
> 
> ::: build/automation.py.in
> @@ +70,5 @@
> >  #expand _DEFAULT_APP = "./" + __BROWSER_PATH__
> >  #expand _CERTS_SRC_DIR = __CERTS_SRC_DIR__
> >  #expand _IS_TEST_BUILD = __IS_TEST_BUILD__
> >  #expand _IS_DEBUG_BUILD = __IS_DEBUG_BUILD__
> > +#expand _CRASHREPORTER = MOZ_CRASHREPORTER == 1
> 
> __CRASHREPORTER__ is expanded here:
> http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py#356

Yeah, I realized my mistake on the bus ride in to work.  Thanks for the quick review; I'm going to carry the r= onto the fixed version and land shortly.
(Assignee)

Comment 8

5 years ago
(In reply to Nick Alexander :nalexander from comment #7)
> (In reply to Joel Maher (:jmaher) from comment #6)
> > Comment on attachment 739665 [details] [diff] [review]
> > Patch against m-i
> > 
> > Review of attachment 739665 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > lets fix the crsahreporter definition, otherwise this looks great.
> > 
> > ::: build/automation.py.in
> > @@ +70,5 @@
> > >  #expand _DEFAULT_APP = "./" + __BROWSER_PATH__
> > >  #expand _CERTS_SRC_DIR = __CERTS_SRC_DIR__
> > >  #expand _IS_TEST_BUILD = __IS_TEST_BUILD__
> > >  #expand _IS_DEBUG_BUILD = __IS_DEBUG_BUILD__
> > > +#expand _CRASHREPORTER = MOZ_CRASHREPORTER == 1
> > 
> > __CRASHREPORTER__ is expanded here:
> > http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py#356
> 
> Yeah, I realized my mistake on the bus ride in to work.  Thanks for the
> quick review; I'm going to carry the r= onto the fixed version and land
> shortly.

No I'm not -- that was an r-.  Will re-post updated patch for r+.
(Assignee)

Comment 9

5 years ago
Created attachment 739704 [details] [diff] [review]
v2. Don't bork __CRASHREPORTER__.
Attachment #739665 - Attachment is obsolete: true
Attachment #739704 - Flags: review?(jmaher)
Comment on attachment 739704 [details] [diff] [review]
v2. Don't bork __CRASHREPORTER__.

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

big thanks for proper comments and updating the other ones!
Attachment #739704 - Flags: review?(jmaher) → review+
(Assignee)

Comment 11

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac14e49337b8

Probably could have marked this DONTBUILD, but if it breaks the test-suite I'd like to know.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla23
https://hg.mozilla.org/mozilla-central/rev/ac14e49337b8
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.