I have seen this ever since bug 71911 was resolved, and --disable-debug worked. This occurs when using MIPSpro, and since gcc on IRIX is now working, I will soon be testing it on that. % ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= moz_run_program[36]: 12869042 Memory fault(coredump) % dbx mozilla-bin core dbx version 7.3.1 68542_Oct26 MR Oct 26 2000 17:50:34 Core from signal SIGBUS: Bus error (dbx) where > 0 NewParseNode(0x6b, 0x30, 0x0, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":148, 0x41fe640] 1 PrimaryExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2943, 0x420526c] 2 MemberExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x0, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2572, 0x4204b18] 3 UnaryExpr(0x0, 0x10135d30, 0x0, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2492, 0x4204608] 4 MulExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2361, 0x420429c] 5 AddExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2343, 0x4204170] 6 ShiftExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2328, 0x4204074] 7 RelExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2296, 0x4203f24] 8 EqExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2274, 0x4203e70] 9 BitAndExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2259, 0x4203d44] 10 BitXorExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2246, 0x4203c74] 11 BitOrExpr(0x10151340, 0x10135d30, 0x7fff0fb8, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2233, 0x4203ba4] 12 AndExpr(0x10151340, 0x0, 0x0, 0x21, 0x0, 0x10151340, 0x10135d78, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2222, 0x4203acc] 13 OrExpr(0x1003ad90, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2211, 0x4203a0c] 14 OrExpr(0x1003ad90, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2213, 0x4203a50] 15 CondExpr(0x1003ad90, 0x1012b480, 0x7fff0fb8, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2171, 0x4203834] 16 AssignExpr(0x1003ad90, 0x1012b480, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2117, 0x4203620] 17 Expr(0x1003ad90, 0x1012b480, 0x7fff0fb8, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":2091, 0x420349c] 18 Condition(0x0, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":934, 0x420029c] 19 Statement(0x1003ad90, 0x1012b480, 0x7fff0fb8, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":1178, 0x4201310] 20 Statements(0x1003ad90, 0x1012b480, 0x7fff0fb8, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":882, 0x4200050] 21 FunctionBody(0x1003ad90, 0x1012b480, 0x1013d4a8, 0x7fff0fb8, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":549, 0x41ff3a8] 22 FunctionDef(0x1003ad90, 0x1012b480, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":716, 0x41ffb14] 23 Statement(0x1003ad90, 0x1012b480, 0x7fff12b0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":1164, 0x4201410] 24 Statements(0x1003ad90, 0x1012b480, 0x7fff12b0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":882, 0x4200050] 25 js_CompileTokenStream(0x1003ad90, 0x10125750, 0x1012b480, 0x7fff12b0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jspars e.c":391, 0x41fee58] More (n if no)? 26 CompileTokenStream(0x1003ad90, 0x10125750, 0x1012b480, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jsapi. c":2801, 0x41ab994] 27 JS_CompileUCScriptForPrincipals(0x0, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jsapi. c":2880, 0x41abcb8] 28 JS_EvaluateUCScriptForPrincipals(0x1003ad90, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x0) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jsapi. c":3286, 0x41acc9c] 29 JS_EvaluateUCScript(0x6b, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jsapi. c":3271, 0x41acc54] 30 JS_EvaluateScript(0x1003ad90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/jsapi. c":3239, 0x41acb04] 31 PREF_EvaluateConfigScript(0x6b, 0xaa4, 0x0, 0x0, 0x0, 0x0, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/prefapi.c":507, 0x4b596cc] 32 ::openPrefFileSpec(nsIFileSpec*,int,int,int,int)(0x0, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPrefService.cpp":408, 0x4b661ec] 33 ::openPrefFile(nsIFile*,int,int,int,int)(0x0, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPrefService.cpp":368, 0x4b65ff8] 34 ::pref_InitInitialObjects(0x7fff15b4, 0x7fff1558, 0x0, 0x21, 0x0, 0x7fff15b4, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPrefService.cpp":601, 0x4b66c10] 35 PREF_Init(0x6b, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/prefapi.c":334, 0x4b592d0] 36 nsPrefService::Init(void)(0x0, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPrefService.cpp":111, 0x4b68b14] 37 ::nsPrefServiceConstructor(nsISupports*,const nsID&,void**)(0x6b, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPrefsFactory.cpp":36, 0x4b6a060] 38 nsComponentManagerImpl::CreateInstance(const nsID&,nsISupports*,const nsID&,void**)(0x6b, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsComponentManager.cpp":1 39 nsComponentManager::CreateInstance(const nsID&,nsISupports*,const nsID&,void**)(0x0, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsRepository.cpp":81, 0x40d07e 40 nsServiceManagerImpl::GetService(const nsID&,const nsID&,nsISupports**,nsIShutdownListener*)(0x0, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsServiceManager. 41 nsServiceManagerImpl::GetService(const char*,const nsID&,nsISupports**,nsIShutdownListener*)(0x0, 0x30, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsServiceManager 42 nsServiceManager::GetService(const char*,const nsID&,nsISupports**,nsIShutdownListener*)(0x0, 0x0, 0x0, 0x0, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsServiceManager.cpp" 43 nsGetServiceByContractID::operator()(const nsID&,void**) const (0x7fff1a88, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsServiceManager.cpp":64, 0x40d1d68] 44 nsCOMPtr_base::assign_from_helper(const nsCOMPtr_helper&,const nsID&) (0x6b, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/base/ns COMPtr.cpp":65, 0x406de68] 45 nsCOMPtr<nsIPrefService>::nsCOMPtr<nsIPrefService>(const nsCOMPtr_helper&) (0x7fff1a9c, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/workarea/dist/include /nsCOMPtr.h":552, 0x4b5d8a0] 46 nsPref::nsPref(void)(0x10110a60, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPref.cpp":139, 0x4b60870] 47 nsPref::GetInstance(void)(0x6b, 0x1, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPref.cpp":762, 0x4b5da40] 48 ::nsPrefConstructor(nsISupports*,const nsID&,void**)(0x6b, 0x0, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/modules/libpr ef/src/nsPref.cpp":793, 0x4b5cfc8] ... 73 mozJSComponentLoader::AutoRegisterComponents(int,nsIFile*)(0x6b, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/js/src/xpconn ect/loader/mozJSComponentLoader.cpp":535, 0x5d75fac] 74 ::AutoRegister_enumerate(nsHashKey*,void*,void*)(0x6b, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/compone nts/nsComponentManager.cpp":1928, 0x40bbf20] 75 ::_hashEnumerate(PLHashEntry*,int,void*)(0x6b, 0x30, 0x0, 0x21, 0x0, 0x1003ad90, 0x1012b4c8, 0x3b) ["/projects/sise/mozilla/devel/workpits/moz/latest_nodebug/mozilla/xpcom/ds/nsHa shtable.cpp":191, 0x4078f98] 76 <Unknown>() [< unknown >, 0x427a900] (dbx)

updating component

is it not --enable-optimize?

What version of MIPSpro?

Sadly the configure script isnt localised ... and I just typed what was logical for my fingers to type. --enable-optimize (en-US) = --enable-optimise (en-AU) % CC -version MIPSpro Compilers: Version 7.3.1.2m

This really should be assigned to the JS group.

cc'ing Brendan on this one -

Optimisation level 1 does not cause this problem; -O2 and -Ofast do, however - Ofast results in a different core file. % ./mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= moz_run_program[36]: 18724529 Memory fault(coredump) % dbx mozilla-bin core dbx version 7.3.1 68542_Oct26 MR Oct 26 2000 17:50:34 where Core from signal SIGSEGV: Segmentation violation (dbx) > 0 EmitCheck(0x100f6600, 0x0, 0x0, 0x3, 0x0, 0x128b20, 0x0, 0xffffffff) ["/projects/sise/mozilla/devel/workpits/moz/latest_opt/mozilla/js/src/jsemit.c": 118, 0x41b7da4] 1 js_Emit3(0x0, 0x0, 0x0, 0x0, 0x0, 0x128b20, 0x0, 0xffffffff) ["/projects/sise/mozilla/devel/workpits/moz/latest_opt/mozilla/js/src/jsemit.c": 191, 0x41b8178] 2 js_EmitTree(0x100f6600, 0x7fff14e0, 0x10109b98, 0x0, 0x100ecd48, 0x0, 0x2, 0xffffffff) ["/projects/sise/mozilla/devel/workpits/moz/latest_opt/mozilla/js/src/jsemit.c": 998, 0x41ba1d4] 3 Statements(0x100f6600, 0x10109820, 0x7fff14e0, 0x3, 0x0, 0x128b20, 0x0, 0xffffffff) ["/projects/sise/mozilla/devel/workpits/moz/latest_opt/mozilla/js/src/jsparse.c" :909, 0x41f44b4] 4 js_CompileTokenStream(0x100f6600, 0x10125b50, 0x10109820, 0x7fff14e0, 0x0, 0x128b20, 0x0, 0xffffffff) ["/projects/sise/mozilla/devel/workpits/moz/latest_opt/mozilla/js/src/jsparse.c" :391, 0x41f31f8] ...

Compare bug 86687, also involving a crash with MIPSpro compiler on IRIX -

I have tried the solution for bug 30427, -OPT:wn_simplify=off , to no avail. I have been able to fix this by preceed jsparse.c:148 with printf("Before"). It then dies on JS_ARENA_ALLOCATE_CAST in jsemit.c. I can then put a printf ("Blah") in the JS_ARENA_ALLOCATE_CAST macro, and several JS_ARENA_ALLOCATE_CAST do succeed before it still fails in jsemit.c:118 . Here is the sequence I get. I can probably raise a bug against MIPSpro with the info I have now. BlahBlahBeforeBlahBlahBeforeBlahBeforeBlahBeforeBlahBeforeBlahBeforeBlahBlahBefo reBlahBeforeBlahBeforeBlahBeforeBlahBlahBeforeBlahBeforeBlahBeforeBlahBeforeBlah BlahBeforeBlahBlahBlahBlahBlahBlahBlahBlahBlah

Not sure whether var is able to help still, reassigning to find out. /be

This looks like a DUPlicate of bug 74882, see my comments there ...

zeroJ@null.net: do you agree that this as a duplicate of bug 74882, as Roland has suggested? Or do you think this is a different issue?

Added myself to cc list

I no longer have access to an IRIX box, however this is not simply a duplicate of bug 74882, as there are at least two bugs (see comment #7) relating to MIPSpro optimisation levels and jsparse.c

There is numerous problems here, one in particular that is easy (-ish) to define. I can get a higher optimisation level (-O2) for most of the files in the js/src directory, but these definetly files need -O1: jsapi.c jsemit.c jsfun.c jsinterp.c jsopcode.c jsparse.c jsregexp.c jsscript.c And they all seem to have problems with the JS_AREA_RELEASE() macro. And also: jsarena.c jsarray.c jsarom.c But I am not sure (yet!) where these ones crash, they seem to end up passing bogus data down the line (and crash in jshash.c).

Better and better! :) I can get -O3 for all the js/src/ files, except the ones mentioned above...

err, s/jsarom/jsatom/ in the above post, oops!

This is a workaround, not a fix (eg please don't close this bug), but simply drops the optimisation level down to -O1 for the files mentioned above. This allows me to get a -O3 or -Ofast build happening.

cc'ing dbaron, timeless in case they have insights into building with these optimization levels on IRIX -

the only irix i could play w/ was antitux's and that's gone. Overall I don't like the patch, but i'd prefer for whatever trick we use to only happen once in the makefile... (again, my opinions don't matter)

Please to be using a static pattern rule, e.g. $(AFFLICTED_OBJECTS): %.o: %.c Makefile.in + $(CC) -o $@ -c $(shell echo $(COMPILE_CFLAGS) | sed 's/-O\([23]\|fast\)/-O1/g') $< So you don't have to repeat the same rule command over and over. Is there no hope of a final diagnosis (either the compiler is busted, or there is a bug in the JS code that only this compiler, only when given -O([23]|fast) yet, notices)? Victor, are you reading bugmail? /be

Essentially the same as 59489, but as a single (static pattern) rule.

same as 60373, sorry, attached wrong file.

Comment on attachment 60374 [details] [diff] [review] js/src/Makefile.in - forces -O1 for some files I'll delegate my sr= to cls and r= this patch. The bug should stay open until we have a better solution, methinks. /be

Cc'ing cls for his build-fu blessing. /be

It looks like there are two problems here, one of which is almost definetly a compiler bug. I am still in the process of isolating and simplfying the problem(s), and have been in contact with the compiler group at SGI. However, I would definetly prefer this bug was kept open until a proper solution is found (newer compiler, better workaround etc). Thanks.

FWIW, I don't see this problem with a -O2 build using MIPSpro 7.2.1.3m . I don't like the sed expression in the duplicated ruleset as it seems like there are potential optimizations that could be missed, but since this is just temporary, sr=cls.

Nick: your patch (id=60374) has r= and sr=. Do you have checkin rights to CVS? If so, this patch can be checked in now. Could you add a note here when that is done? Thanks. As Brendan suggested in Comment #24, however, we should continue to keep the bug open -

Unfortunetly, I don't have CVS write access :( Chris, could you perhaps check this in please? And yes, I definetly would prefer this was kept open, until a real solution is found (I'm working on it! -- as with 113511). thanks.

Patch has been checked in.

About comment #11: I still this is a DUPLICATE of bug 74882 - it seems that this issue is a problem of "too agressive" optimisations (-fsimple=2 for the Sun Workshop 6 compiler) which may cause that floating-point data are somehow misaligned. The resulting crash may be a side-effect of this problem ... Is it somehow possible to disable optimisations for floating-point operations in the SGI compiler ?

It is my understanding that -O2 should not affect floating point accuracy (and presumably alignment), whereas -O3 can, and -Ofast definetly reorders floating point computations. Since we are seeing these problems at -O2 I would suggest this is not the problem. I have tried using the following options (with -O3), to no avail: -OPT:fold_reassociate=OFF:IEEE_arithmetic=1:roundoff=0 The man page entries for these options are: fold_reassociate[ = ( ON|OFF )] fold_reassociate=ON allows optimizations involving reassociation of floating-point quantities. The default is OFF. fold_reassociate=ON is enabled automatically when -O3 is in effect or when -OPT:roundoff=2 or greater is in effect. IEEE_arithmetic=n Specifies the level of conformance to ANSI/IEEE 754-1985, the IEEE Standard for Binary Floating-point Arithmetic, which describes a standard for, among other things, NaN and inf operands, arithmetic round off, and overflow. n can be one of the following: n Description 1 Inhibits optimizations that produce less accurate results than required by ANSI/IEEE 754-1985. This is the default. roundoff=n Specifies the level of acceptable departure from source language floating-point, round-off, and overflow semantics. n can be one of the following: n Description 0 Inhibits optimizations that might affect the floating-point behavior. This is the default when optimization levels -O0, -O1, and -O2 are in effect. I shall keep looking for any other floating point related optimisation options, but these seem to be the main ones.

The other thing that makes me think this is not a floating point problem is the way the pointers get messed up, eg (this crash was caused by compiling jsemit.c only at -O2): (dbx) where 5 0 JS_ArenaAllocate(pool = 0x10144108, nb = 16) ["/projects/sise/mozilla/devel/workpits/moz/0.9.5_branch_m_d/mozilla/js/src/jsarena.c":99, 0x40202bc] 1 js_alloc_temp_entry(priv = 0x10144098, key = 0x101342b0) ["/projects/sise/mozilla/devel/workpits/moz/0.9.5_branch_m_d/mozilla/js/src/jsatom.c":714, 0x4026e80] 2 JS_HashTableRawAdd(ht = 0x10159148, hep = 0x400, keyHash = 269484176, key = 0x40d83f8, value = (nil)) ["/projects/sise/mozilla/devel/workpits/moz/0.9.5_branch_m_d/mozilla/js/src/jshash.c":242, 0x404f768] 3 js_IndexAtom(cx = 0x10144098, atom = 0x101342b0, al = 0x7ffe6cac) ["/projects/sise/mozilla/devel/workpits/moz/0.9.5_branch_m_d/mozilla/js/src/jsatom.c":776, 0x4027144] 4 js_EmitTree(cx = 0x10144098, cg = 0x7ffe6c58, pn = 0x1013d968) ["/projects/sise/mozilla/devel/workpits/moz/0.9.5_branch_m_d/mozilla/js/src/jsemit.c":999, 0x403bdf0] (dbx) list 97 97 98 JS_ASSERT((nb & pool->mask) == 0); * 99 for (a = pool->current; a->avail + nb > a->limit; pool->current = a) { 100 if (!a->next) { 101 ap = &arena_freelist; 102 JS_ACQUIRE_LOCK(arena_freelist_lock); 103 while ((b = *ap) != NULL) { /* reclaim a free arena */ 104 /* 105 * Insist on exact arenasize match if nb is not greater than 106 * arenasize. Otherwise take any arena big enough, but not by (dbx) print *pool struct JSArenaPool { first = struct JSArena { next = 0x1013d2f8 base = 269762840 limit = 269762840 avail = 269762840 } current = 0xdadadada arenasize = 1024 mask = 7 } note current = 0xdadadada This address (0xdadadada) seems to occur often in this code, when compiled at -O2 or above.

Some further news: Apparently it is not possible to disable floating point optimisations, although the swicthes -OPT:roundoff=0:IEEE_arithmetic=1:fold_reassociate=OFF:IEEE_NaN_inf=on should ensure accuracy.

For some reason 0.9.8 has this worse then before -- I have had to drop the optimisation level to nothing on these files to run mozilla... :( Investigating now.

The current sed rule misses -O, which is equivilent to -O2 and therefor needs to be altered to -O1 for js to work properly.

If we change JS_ARENA_RELEASE to a function rather then macro we do not have to restrict the optimisations on as many files (which supports my belief that we have two seperate problems here).

What might the other problem be, if not also a compiler bug? /be

Ah sorry, no, most likely also a compiler bug.... just a different one! Or at least manifest in a different way.

So, it looks like the first of these problems (the macro related one) is essentially the same as BZ 71911, except that the same fix will not work here! Further, this would explain why cls didn't see the problem with 7.3.1.3, as this problem was fixed for BZ 71911. Still looking at the second problem.

The other problem only seems to manifest itself at -O3, so we can change the makefile a bit. (see attachment 66415 [details] [diff] [review] in conjunction with attachment 66379 [details] [diff] [review] and attachment 66380 [details] [diff] [review])

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Adding myself to CC list. I've tried just compiling jsinterp.c at -O3 (with the other problem files at -O1). JS_ARENA_ALLOCATE_CAST is causing me a problem. It's called from js_Interpret (via js_AllocRawStack). For the time it goes wrong, JS_ARENA_ALLOCATE_CAST does not call JS_ArenaAllocate (i.e.: it returns something out of the current pool [apologies if I'm using the wrong terminology]). The crash is caused by JS_ARENA_ALLOCATE_CAST returning part of js_Interpret's stack frame (which causes a segfault later on...). Under -O1, JS_ARENA_ALLOCATE_CAST does not return addresses anywhere near js_Interpret's stack frame. I've not yet discovered what changes (the value in JS_ARENA_ALLOCATE_CAST that's called) _a->avail (or cx->stackPool.current->avail, in most functions), but it looks like this is getting corrupted somewhere. Ralph

ralpht@sgi.com: Does it help to place some |volatile|s in the code to work around the problem ?

fwiw, File jsarena.h: #define JS_FREE_PATTERN 0xDA is the cause of 0xdadadada ... JS_ArenaAllocate(JSArenaPool *pool, size_t nb) { ... for (a = pool->current; a->avail + nb > a->limit; pool->current = a) { ... if (!*ap) { ... while ((b = *bp) != NULL) { ... if (extra ? sz >= gross && sz <= gross + pool->arenasize : sz == gross) { ... b->next = NULL; <- is it possible this was optimized away?

I can reproduce the crash reported in comment #7. The proposed patches to make JS_ARENA_RELEASE a function ( Attachment #66379 [details] [diff] and #66380) seem to fix the problem. Details: I use js-1.5-rc5 embedded in a own application. Compiler: MIPSpro Compilers: Version 7.3.1.2m Debug build: -O0 -g

Is this something we can drive to completion or should it just be dropped?

imo we should drive it to completion

Note that bug 351261 is a more critical case of this problem. Im not sure if it should be closed as a dup, as the patch there is reported to fix the immediate problem.

SpiderMonkey is compiled as C++ now, so old compiler bugs that haven't yet been fixed are incomplete.