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

Status: NEW

(Testing :: Mozbase, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

[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.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

[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.

Comment 2

[Benjamin Smedberg]

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.

Comment 3

[Lawrence Mandel [:lmandel] (use needinfo)]

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?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Those are all builds from ftp.mozilla.org. Just the default daily builds across all the channels.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 8

[Nathan Froyd [:froydnj]]

(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

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 10

[Nicholas Nethercote [inactive]]

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.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 12

[(not currently active) Ted Mielczarek]

(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.)

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

For reference the changeset which reverted it was:

https://hg.mozilla.org/mozilla-central/rev/e3ba56da078a