User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/9.04 (CK-IBM) (CK-IBM) Firefox/3.6.8
Build Identifier: Ubuntu firefox-3.6.8+build1+nobinonly on armel-linux
The Ubuntu firefox-3.6.8+build1+nobinonly package fails to build from source on armv7l-unknown-linux-gnueabi using the GCC 4.4.4-7ubuntu3 compiler, due to a crash (segmentation fault) of the "js" interpreter used during the build.
Analysis seems to point to a bug in the underlying Mozilla sources that just happen to trigger due to random compiler and/or code changes.
The immediate cause of the crash is that a global array is only 4-byte aligned, but the code silently assumes 8-byte alignment.
The problem triggers in jsatom.cpp:js_AtomizeString:
jsapi.h:STRING_TO_JSVAL uses the low 3 bits of the pointer value to encode the type of the atom. This works only if all pointers passed to STRING_TO_JSVAL are guaranteed to be 8-byte aligned.
This is usually not a problem if the value is dynamically allocated. But in this particular instance, JSString::unitString returns the address of a global variable (jsstrinlines.h):
The array unitString Table is a static member of the JSString class (jsstr.h):
static JSString unitStringTable[];
The compiler assumes that the alignment requirement of that static variable derive from the alignment requirement of the JSString type. Since this type has only two members, a size_t and a union of two pointer types, the total alignment requirement on a platform with 32-bit pointers like ARM is 4 bytes.
As it so happens, in the build of the "js" executable with this compiler and options, the variable does actually turn out to reside at an address that is only 4-byte aligned, but not 8-byte aligned:
000cc034 d JSString::unitStringTable
It seems to me that this is not a compiler bug, just something that can be triggered by random changes in the compiler ...
Interestingly enough, there is code in jsstr.h to ensure 8-byte alignment for unitStringTable, but only on Solaris:
I guess it looks like a more generic fix for this problem is required. I'm wondering why this never triggered elsewhere ... Is there anything I'm missing that would make this work reliably?
Reproducible: Always
Steps to Reproduce:
1. Install Ubuntu maverick on armel-linux
2. Build the firefox-3.6.8+build1+nobinonly package from source
3. Build aborts with a JS crash:
gcc -c -x c -E -P -I. imacro_asm.js.in > imacro_asm.js
./../../dist/bin/run-mozilla.sh ./../../dist/bin/js imacro_asm.js ./imacros.jsasm > imacros.c.tmp
Segmentation fault
make[4]: *** [libs] Error 139
make[4]: Leaving directory `/build/buildd/firefox-3.6.6+nobinonly/build-tree/mozilla/js/src'
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/9.04 (CK-IBM) (CK-IBM) Firefox/3.6.8 3.6.8+build1+ nobinonly on armel-linux
Build Identifier: Ubuntu firefox-
The Ubuntu firefox- 3.6.8+build1+ nobinonly package fails to build from source on armv7l- unknown- linux-gnueabi using the GCC 4.4.4-7ubuntu3 compiler, due to a crash (segmentation fault) of the "js" interpreter used during the build.
Analysis seems to point to a bug in the underlying Mozilla sources that just happen to trigger due to random compiler and/or code changes.
The immediate cause of the crash is that a global array is only 4-byte aligned, but the code silently assumes 8-byte alignment.
The problem triggers in jsatom. cpp:js_ AtomizeString:
return (JSAtom *) STRING_ TO_JSVAL( JSString: :unitString( c));
jsapi.h: STRING_ TO_JSVAL uses the low 3 bits of the pointer value to encode the type of the atom. This works only if all pointers passed to STRING_TO_JSVAL are guaranteed to be 8-byte aligned.
This is usually not a problem if the value is dynamically allocated. But in this particular instance, JSString: :unitString returns the address of a global variable (jsstrinlines.h):
inline JSString * :unitString( jschar c) e[c];
JSString:
{
JS_ASSERT(c < UNIT_STRING_LIMIT);
return &unitStringTabl
}
The array unitString Table is a static member of the JSString class (jsstr.h):
static JSString unitStringTable[];
The compiler assumes that the alignment requirement of that static variable derive from the alignment requirement of the JSString type. Since this type has only two members, a size_t and a union of two pointer types, the total alignment requirement on a platform with 32-bit pointers like ARM is 4 bytes.
As it so happens, in the build of the "js" executable with this compiler and options, the variable does actually turn out to reside at an address that is only 4-byte aligned, but not 8-byte aligned:
000cc034 d JSString: :unitStringTabl e
It seems to me that this is not a compiler bug, just something that can be triggered by random changes in the compiler ...
Interestingly enough, there is code in jsstr.h to ensure 8-byte alignment for unitStringTable, but only on Solaris:
#ifdef __SUNPRO_CC unitStringTable _, __1cIJSStringOi ntStringTable_ )
#pragma align 8 (__1cIJSStringP
#endif
static JSString unitStringTable[]; ingTable[ ];
static JSString intStringTable[];
static const char *deflatedIntStr
I guess it looks like a more generic fix for this problem is required. I'm wondering why this never triggered elsewhere ... Is there anything I'm missing that would make this work reliably?
Reproducible: Always
Steps to Reproduce: 3.6.8+build1+ nobinonly package from source /dist/bin/ run-mozilla. sh ./../../dist/bin/js imacro_asm.js ./imacros.jsasm > imacros.c.tmp buildd/ firefox- 3.6.6+nobinonly /build- tree/mozilla/ js/src'
1. Install Ubuntu maverick on armel-linux
2. Build the firefox-
3. Build aborts with a JS crash:
gcc -c -x c -E -P -I. imacro_asm.js.in > imacro_asm.js
./../..
Segmentation fault
make[4]: *** [libs] Error 139
make[4]: Leaving directory `/build/
Actual Results: launchpadlibrar ian.net/ 51627119/ buildlog_ ubuntu- maverick- armel.firefox_ 3.6.6%2Bnobinon ly-0ubuntu1_ FAILEDTOBUILD. txt.gz
http://
Expected Results:
Build succeeds.
See also Ubuntu bug report at: /bugs.launchpad .net/gcc- linaro/ +bug/604874
https:/