mozrunner should allow to start the binary in 32bit or 64bit mode on OS X

NEW
Unassigned

Status

Testing
Mozbase
3 years ago
3 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mozmill])

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

As seen today when checking our Mozmill test results for the newly brought up OS X 10.10 machine, we completely fail in our endurance tests in getting the explicit memory. This failure only occurs for the upcoming OS X 10.10 release. Any other version is running fine without problems.

Here the failure as we can see:

ERROR | Test Failure | {
   "exception": {
     "message": "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIMemoryReporterManager.explicit]", 
     "lineNumber": 89, 
     "name": "NS_ERROR_NOT_AVAILABLE"
   }
}

I will check which other branches are affected.
[Tracking Requested - why for this release]:
This affects every supported branch. Given that I'm not sure about implications of this behavior, I'm asking for tracking.
status-firefox33: ? → affected
status-firefox-esr31: ? → affected
tracking-firefox33: --- → ?
Blocks: 1079895

Comment 2

3 years ago
Other than that mozmill and about:memory can't measure explicit memory, I don't see how this would be a user-facing issue that we'd need to track.
We may still track test specific issues if they impact our ability to measure a release quality attribute or to debug issues. Does this issue fall into either of these buckets?
Beside Mozmill also https://areweslimyet.com/ might be affected on OS X 10.10 (if they run or will start to run tests on that platform). AFAIK they are making use of our modules to run tests. But not that sure about that anymore. We may have to ask someone who knows that.
That return value means HAVE_JEMALLOC_STATS was not defined.  Which also means MOZ_MEMORY was not defined, no?

Where did you get the build you were using, exactly?
Flags: needinfo?(hskupin)
Those are all builds from ftp.mozilla.org. Just the default daily builds across all the channels.
Flags: needinfo?(hskupin)
I tested outside of Mozmill and it worked. So I digged deeper and finally have seen that mozrunner itself is starting Firefox via `arch -arch i386`. I can remember that Nathan mentioned something to me with 32bit, but not sure what it exactly was. Could this be related? If yes, mozrunner seems to be broken and we should move this bug into testing/mozbase.
(In reply to Henrik Skupin (:whimboo) from comment #7)
> I tested outside of Mozmill and it worked. So I digged deeper and finally
> have seen that mozrunner itself is starting Firefox via `arch -arch i386`. I
> can remember that Nathan mentioned something to me with 32bit, but not sure
> what it exactly was. Could this be related?

Yes, that would be a result of:

http://mxr.mozilla.org/mozilla-central/source/configure.in#1938
Something is clearly broken in mozrunner here. The newest version 6.3 works without issues, but doesn't have the support for starting the application in 32bit mode anymore. This is necessary for our mozmill tests. So this is not Firefox Core. Moving out to mozbase for further investigation.
Status: NEW → ASSIGNED
status-firefox33: affected → ---
status-firefox34: affected → ---
status-firefox35: affected → ---
status-firefox-esr31: affected → ---
tracking-firefox33: ? → ---
tracking-firefox34: ? → ---
tracking-firefox35: ? → ---
Component: XPCOM → Mozbase
Product: Core → Testing
QA Contact: hskupin
Comment 5 gets to the heart of the matter: if MOZ_MEMORY is not defined then jemalloc won't be used, which means nsIMemoryReporterManager.explicit won't work.
Blocks: 1059264
Blocks: 1082077
So what has to happen here is that we have to re-introduce the arch feature to mozrunner. It has been ripped off by the refactoring done by Andrew via bug 997244. Since version 6.0 of mozrunner you can only start Firefox in 64bit mode on OS X but not 32bit.

Given that this would mean for Mozmill that we have to upgrade mozrunner from 5.35 to >6.0, I would not stick this into the 2.0.9 release, but wait for 2.1 to follow-up soonish. Since then we have to wait with OS X 10.10 support in Mozmill.
Blocks: 970594, 997244
No longer blocks: 1082077
Status: ASSIGNED → NEW
Keywords: regression
Hardware: x86_64 → All
Summary: nsIMemoryReporterManager.explicit is not available on OS X 10.10 → mozrunner should allow to start the binary in 32bit or 64bit mode on OS X
Version: 35 Branch → unspecified
(In reply to Henrik Skupin (:whimboo) from comment #11)
> So what has to happen here is that we have to re-introduce the arch feature
> to mozrunner. It has been ripped off by the refactoring done by Andrew via
> bug 997244. Since version 6.0 of mozrunner you can only start Firefox in
> 64bit mode on OS X but not 32bit.

I'm not clear why this is? Surely you only want to run the 64-bit binary on OS X 10.10? Are you just hitting a bug where the crappy hack we used to have does the wrong thing on 10.10? (We hit that in Mochitest and it was fixed in bug 1054043.)
Thank you Ted. So this is indeed a regression from bug 1054043 then. Yes, we want to be able to start Firefox in 32bit mode via mozrunner. There were some critical bugs in the past, because no-one actually tests with this mode.
Blocks: 1054043
No longer blocks: 997244
For reference the changeset which reverted it was:

https://hg.mozilla.org/mozilla-central/rev/e3ba56da078a
No longer blocks: 1059264
You need to log in before you can comment on or make changes to this bug.