600514 - [@ JS_XDRString] (xdr=0x46333d30, strp=0xbe8d7eb4) at jsxdrapi.cpp:455 with gcc 4.4.1 because it's buggy

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Oleg Romashin (:romaxa)]

Building fennec with m-c:
http://hg.mozilla.org/mozilla-central/rev/a60414d076b5

Compiling with gcc 4.4.1
sbox-arm-none-linux-gnueabi-gcc ('cs2009q3-67-hard-sb5') 4.4.1

and have this crash on startup

#0  0x4004891c in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:45
#1  0x42fcd694 in nsProfileLock::FatalSignalHandler (signo=11, info=<value optimized out>, context=0xbe8d7998) at nsProfileLock.cpp:213
#2  <signal handler called>
#3  JS_XDRString (xdr=0x46333d30, strp=0xbe8d7eb4) at js/src/jsxdrapi.cpp:455
#4  0x43fcac8c in js_XDRAtom (xdr=0x46333d30, atomp=0xbe8d7f20) at js/src/jsxdrapi.cpp:635
#5  0x43f1d6e8 in js_XDRFunctionObject (xdr=0x46333d30, objp=<value optimized out>) at js/src/jsfun.cpp:1969
#6  0x43fa0414 in js_XDRScript (xdr=0x46333d30, scriptp=0xbe8d8074, needMutableScript=<value optimized out>, hasMagic=<value optimized out>)
    at js/src/jsscript.cpp:340
#7  0x43fc9a9c in JS_XDRScript (xdr=0x46333d30, scriptp=0xbe8d7c8c) at js/src/jsxdrapi.cpp:672
#8  0x43964a68 in WriteScriptToStream (this=<value optimized out>, cache=0x45fe8cc0, script=<value optimized out>, component=<value optimized out>, uri=0x42ba5b30, 
    cx=0x44f955c0) at js/src/xpconnect/loader/mozJSComponentLoader.cpp:465
#9  mozJSComponentLoader::WriteScript (this=<value optimized out>, cache=0x45fe8cc0, script=<value optimized out>, component=<value optimized out>, uri=0x42ba5b30, 
    cx=0x44f955c0) at js/src/xpconnect/loader/mozJSComponentLoader.cpp:919
#10 0x4396530c in mozJSComponentLoader::GlobalForLocation (this=0x42b22790, aComponentFile=<value optimized out>, aURI=<value optimized out>, 
    aGlobal=<value optimized out>, aLocation=0x453eb0c4, exception=0x0)
    at js/src/xpconnect/loader/mozJSComponentLoader.cpp:1218
#11 0x43966460 in mozJSComponentLoader::LoadModuleImpl (this=0x42b22790, aSourceFile=0x452283a0, aKey=..., aComponentURI=<value optimized out>)
    at js/src/xpconnect/loader/mozJSComponentLoader.cpp:728
#12 0x43966e74 in mozJSComponentLoader::LoadModule (this=0x42b22790, aComponentFile=0x452283a0)
    at js/src/xpconnect/loader/mozJSComponentLoader.cpp:663
#13 0x43d653d0 in nsComponentManagerImpl::KnownModule::Load (this=0x453ea2e0)
    at xpcom/components/nsComponentManager.cpp:952
#14 0x43d6541c in nsFactoryEntry::GetFactory (this=0x45fc5ce0) at xpcom/components/nsComponentManager.cpp:1936
#15 0x43d667d4 in nsComponentManagerImpl::CreateInstanceByContractID (this=0x42b28480, aContractID=0x44127c24 "@mozilla.org/addons/integration;1", 
    aDelegate=<value optimized out>, aIID=..., aResult=0xbe8d84c0)
---Type <return> to continue, or q <return> to quit---
    at xpcom/components/nsComponentManager.cpp:1299
#16 0x43d67458 in nsComponentManagerImpl::GetServiceByContractID (this=0x42b28480, aContractID=<value optimized out>, aIID=<value optimized out>, 
    result=<value optimized out>) at xpcom/components/nsComponentManager.cpp:1664
#17 0x43d1f8b8 in nsGetServiceByContractID::operator() (this=<value optimized out>, aIID=..., aInstancePtr=0x0) at nsComponentManagerUtils.cpp:278
#18 0x43d1e79c in nsCOMPtr_base::assign_from_gs_contractid (this=0xbe8d8520, gs=..., iid=<value optimized out>) at nsCOMPtr.cpp:132
#19 0x42fca21c in nsCOMPtr (this=0xbe8d8778) at ../../dist/include/nsCOMPtr.h:627
#20 nsXREDirProvider::DoStartup (this=0xbe8d8778) at toolkit/xre/nsXREDirProvider.cpp:739
#21 0x42fc5df8 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
    at toolkit/xre/nsAppRunner.cpp:3549


(gdb) frame 3
#3  JS_XDRString (xdr=0x46333d30, strp=0xbe8d7eb4) at /home/romaxaxz/microbcomponent/meegohg/mozilla-central/js/src/jsxdrapi.cpp:455
455	        nchars = (*strp)->length();
(gdb) p *strp
$4 = (JSString *) 0x0

Comment 1

[Jan Arne Petersen]

(gdb) frame
#2  0x43f1d778 in js_XDRFunctionObject (xdr=0x4617c0a0, objp=<value optimized out>)
    at /home/petersen/work/mozilla-central/js/src/jsfun.cpp:1969
1969	in /home/petersen/work/mozilla-central/js/src/jsfun.cpp
(gdb) p fun->nargs
$47 = 3
(gdb) p fun->u
$48 = {n = {native = 0x1, clasp = 0x0, trcinfo = 0x45254240}, i = {nvars = 1, nupvars = 0, skipmin = 0, 
    wrapper = 0 '\000', script = 0x45254240, names = 0x46158108}}
(gdb) p names[0]
$50 = 1174425440
(gdb) p names[1]
$51 = 1174425472
(gdb) p names[2]
$52 = 1174425504
(gdb) p names[3]
$53 = 0

Comment 2

[Jan Arne Petersen]

(gdb) p *fun->u.i.names->parent->parent->parent
$41 = {<JSObjectMap> = {static sharedNonNative = {
      static sharedNonNative = <same as static member of an already seen type>, shape = 4294967295, 
      slotSpan = 0}, shape = 889, slotSpan = 4}, table = 0x0, id = 1174425440, {
    rawGetter = 0x43f1ce40 <js_GetCallArg(JSContext*, JSObject*, int, js::Value*)>, 
    getterObj = 0x43f1ce40, clasp = 0x43f1ce40}, {
    rawSetter = 0x43f1ce1c <SetCallArg(JSContext*, JSObject*, int, js::Value*)>, setterObj = 0x43f1ce1c}, 
  slot = 3, attrs = 69 'E', flags = 64 '@', shortid = 0, parent = 0x453f1060, {kids = {w = 1175559976}, 
    listp = 0x46119f28}}
(gdb) p *fun->u.i.names->parent->parent->parent->parent
$42 = {<JSObjectMap> = {static sharedNonNative = {
      static sharedNonNative = <same as static member of an already seen type>, shape = 4294967295, 
      slotSpan = 0}, shape = 3, slotSpan = 3}, table = 0x0, id = 4, {
    rawGetter = 0x4456a544 <js_CallClass>, getterObj = 0x4456a544, clasp = 0x4456a544}, {rawSetter = 0, 
    setterObj = 0x0}, slot = 4294967295, attrs = 0 '\000', flags = 2 '\002', shortid = 0, parent = 0x0, {
    kids = {w = 1175898370}, listp = 0x4616c902}}

Comment 3

[Jeremias Bosch (:jbos)]

I hope its ok (process wise) i increased this as blocker. Its super important to get fixed. 

=> Fennec does not start at all -> just crashing.

Comment 4

[Oleg Romashin (:romaxa)]

This problem is actually only related to new compiler and hard float point option.

Comment 5

[Jeremias Bosch (:jbos)]

happens also with software

Comment 6

[Stuart Parmenter]

Jacob, do you have any ideas what might be happening here?

Comment 7

[Stuart Parmenter]

also, can you guys reproduce this with the JS test suite in the shell?  It would be good to have a better test case than Fennec doesn't start

Comment 8

[Jan Arne Petersen]

I will try to reproduce it with the JS test suite in the shell.

Comment 9

[Oleg Romashin (:romaxa)]

We have also almost similar problems on 
http://bugs.meego.com/show_bug.cgi?id=4021#c69

Comment 10

[Jacob Bramley [:jbramley]]

(In reply to comment #4)
> This problem is actually only related to new compiler and hard float point
> option.

Can you clarify? Which options are the default?

From what I can tell (from Google), the compiler you're using uses the "hard" ABI variant.

There are three major EABI variants on ARM:

  * "soft": Software floating-point, for compatibility with processors that don't have VFP.

  * "softfp": Hardware floating-point, but using the same calling convention as "soft", to allow applications to use VFP even if some platform components are compiled for the more generic "soft" ABI. This is the ABI that most platforms use today.

  * "hard": Hardware floating-poing, with a calling convention that puts FP arguments into VFP registers. This is not backwards-compatible with the other variants, but provides performance and possibly code-size enhancements. It seems that your compiler is targeting this one.

NanoJIT supports the first two of those (plus the WinCE ABI). I think the XPTC interfaces will also require the "softfp" or "soft" ABI.

If you use a "softfp" tool-chain, you might have more luck. That is, unless you fancy adding "hard" ABI support. It's in my big bucket of things that I want to do, but it's in there with many other things and I wasn't planning on tackling it soon.

----

On another note, it might also interest you to know that I've had a few problems building with 4.4.1, particularly if you're doing a Thumb build. I've not been able to isolate any particular issue, unfortunately. 4.4.3 is considerably better, and I have a 4.5.1 build ready to try out when I get my Tegra back.

You compiler has several patches on top of 4.4.1, though, so it should be Ok.

Comment 11

[Jan Arne Petersen]

Attachment: Running jsapi-tests, crash 1

Comment 12

[Jan Arne Petersen]

Attachment: Running jsapi-tests, crash 2

Comment 13

[Juha Kallioinen]

(In reply to comment #10)
> Can you clarify? Which options are the default?

The default options used are

-march=armv7-a -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard -fno-omit-frame-pointer -mtp=cp15 -fno-strict-overflow -funwind-tables

So we're trying to use the hard float abi.

Comment 14

[Jacob Bramley [:jbramley]]

(In reply to comment #13)
> So we're trying to use the hard float abi.

Yep. Sorry, that isn't going to work without some effort.

It will require porting of the XPCOM stuff, NanoJIT, and Jaeger Monkey, in approximate order of difficultly.

Comment 15

[Jeremias Bosch (:jbos)]

Mhm this does not sound very good. How much time you would expect will the fixing take? Do we talk about days? weeks?

Comment 16

[Mike Shaver (:shaver emeritus)]

I would expect it to take a month of work for someone reasonably familiar with ARM code generation to get it to a reviewable state, passing all tests.

Comment 17

[Siarhei Siamashka]

Can the work be split into parts? For example, can we start with fixing XPCOM first and run some tests with NanoJIT and Jaeger Monkey disabled?

Comment 18

[Jacob Bramley [:jbramley]]

(In reply to comment #17)
> Can the work be split into parts? For example, can we start with fixing XPCOM
> first and run some tests with NanoJIT and Jaeger Monkey disabled?

Yes, that approach is feasible.

The existing XPCOM interface for ARM EABI is here: http://hg.mozilla.org/tracemonkey/file/aa2ca63a88d8/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp

I'd be happy to help if you have questions about how things work.

Comment 19

[Adrian Bunk]

(In reply to comment #5)
> happens also with software

Assuming that should have been "softfp":

cs2009q3 contains a backport of the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45112 bug, and I'd bet a bottle of orange juice that this is the cause for any JS crashes you are also seeing with softfp.

Comment 20

[Siarhei Siamashka]

(In reply to comment #19)
> cs2009q3 contains a backport of the
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45112 bug, and I'd bet a bottle of
> orange juice that this is the cause for any JS crashes you are also seeing with
> softfp.
Thanks for the link. That's a nasty bug.

Comment 21

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Received the crash on Mac OS X:
http://crash-stats.mozilla.com/report/index/13e30536-4ff8-4884-aa81-9f4882101024
while moving window during the time that the auth provider prompt was trying to come up.  The window was mostly out of view due to going from dual monitor setup to single monitor setup.

Comment 22

[Oleg Romashin (:romaxa)]

This crash happens because of broken gcc 4.4.1, and not because of mozilla.

I  would suggest to close it as invalid.