510052 - JS fails to build in debug config in scratchbox

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Ben Combee (:bcombee)]

Attachment: Change to disable assert when using scratchbox

Because of an assert in the JS engine, building Fennec using scratchbox for the Nokia tablets fails.  Talking with vlad on IRC, the new assert fails when running ARM code in scratchbox, because it detects the CPU as x86, not ARM.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 394115 [details] [diff] [review]
Change to disable assert when using scratchbox

That's probably fine, though auxv is likely entirely wrong in scratchbox...

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

No, I think you want to only do the getenv in the debug case.

Is there a bug on fixing the platform detection code?  Is it a bug in how we detect, or how scratchbox reports?

Comment 3

[Ben Combee (:bcombee)]

I can add some logging code to this to see what's returned when an ARM binary is running in SB to see if it's saying x86 or ARM.  That will indicate if the detection code is valid for that run environment.

Comment 4

[Ben Combee (:bcombee)]

OK, tested, the plat[0:2] value loaded when the ARM binary is run in scratchbox on x86 is "i68".  This code needs an alternative way of discovering the architecture of the target ARM platform.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Is that a scratchbox bug that we should file upstream (in addition to working around for now, for sure) or are we detecting in the wrong way generally?

Comment 6

[Ben Combee (:bcombee)]

We could detect the machine type using uname system call, but I don't think that gives us color on the specific ARM architecture.  Since Scratchbox runs ARM binaries using qemu as an user-mode emulator, the kernel is correct in saying it's a x86 app when you read /proc/self/auxv.  qemu overrides some system calls, but not the /proc reads.

We should see if qemu can fix this, but I think a workaround is appropriate for now.  That workaround could just be overriding the value using the environment variable, something we could add to the scratchbox build instructions for Fennec.

Comment 7

[Stuart Parmenter]

is this fixed?

Comment 8

[Andreas Gal :gal]

I don't see the patch on TM. The debug hack in the patch looks ok to me. Lets take it if nobody has a better idea.

Comment 9

[Damon Sicore (:damons)]

Not blocking.  We should make sure this gets in.  Assigning to sayre.  Sayre, can you make sure this gets checked in?

Comment 10

[Damon Sicore (:damons)]

P2.

Comment 11

[Robert Sayre]

http://hg.mozilla.org/tracemonkey/rev/bb0a5cb4bbc3

Comment 12

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/bb0a5cb4bbc3

Comment 13

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0a7b8d517bae

Comment 14

[Samuel Sidler (old account; do not CC)]

These bugs landed after b4 was cut. Moving flag out.