+++ This bug was initially created as a clone of Bug #441934 +++ It fails because of the following: 1) GNOME Shell received SIGSEGV from /usr/lib/libmozjs185.so.0 at startup (i.e. /usr/bin/gnome-shell --replace) 2) 'js' binary segfaults 3) tests fail due to 2. This was fixed in 1.8.5 but one of the patches(static strings) doesn't apply to 1.8.7.
This causes latest gjs to also lost ia64 keyword
Is this related with: https://bugzilla.mozilla.org/show_bug.cgi?id=910845 ?
(In reply to Pacho Ramos from comment #2) > Is this related with: > https://bugzilla.mozilla.org/show_bug.cgi?id=910845 > ? This is a mute point. We will work it for 17.0.0, 1.8.7 will not go stable and will be removed soon as we finish 17.0.0 support and push it to stable.
(In reply to Jory A. Pratt from comment #3) > (In reply to Pacho Ramos from comment #2) > Is this related with: > > https://bugzilla.mozilla.org/show_bug.cgi?id=910845 > ? Exactly. > This is a mute point. We will work it for 17.0.0, 1.8.7 will not go stable > and will be removed soon as we finish 17.0.0 support and push it to stable. I don't understand how Mozilla versioning works, but when you say "We will work it for 17.0.0", are you referring to Firefox? In this case, it's noteworthy that upstream failed to include in time changes by Stephan Schreiber in 17 ESR [1]. And it seems that Gentoo won't fix 17 ESR either [2] or am I missing something? Upstream (and thus Gentoo) >= 24 ESR should be OK, but I can't confirm this at the moment as I can't successfully run Firefox 26 (more on this in separate bugs). BTW, Webkit's JS implementation is similarly broken [3]. Stephan fixed it in Debian during Webkit 1.8 era [4]. But Stephan's patches can't be applied to Webkit 2.0. I think that the same kind of patch rework is necessary for the Webkit 1.8 -> 2.0 transition than for the Firefox 10 ESR -> 17 ESR one. However Stephan seems reluctant to fix Webkit 2.0 again [5] which might be problematic as some GNOME components (e.g. Epiphany, Yelp) rely upon it. Émeric [1] https://bugzilla.mozilla.org/show_bug.cgi?id=910845#c31 [2] https://bugs.gentoo.org/show_bug.cgi?id=487248#c1 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#96 [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#150
(In reply to Émeric Maschino from comment #4) > (In reply to Jory A. Pratt from comment #3) > > (In reply to Pacho Ramos from comment #2) > > Is this related with: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=910845 > > ? > > Exactly. > > > This is a mute point. We will work it for 17.0.0, 1.8.7 will not go stable > > and will be removed soon as we finish 17.0.0 support and push it to stable. > > I don't understand how Mozilla versioning works, but when you say "We will > work it for 17.0.0", are you referring to Firefox? In this case, it's > noteworthy that upstream failed to include in time changes by Stephan > Schreiber in 17 ESR [1]. And it seems that Gentoo won't fix 17 ESR either > [2] or am I missing something? Spidermonkey's versioning now matches that of the rest of Mozilla's products; specifically, each ESR release of Firefox et. al. (so 17.x, 24.x, etc) will be accompanied by a spidermonkey release of the same version. > Upstream (and thus Gentoo) >= 24 ESR should be OK, but I can't confirm this > at the moment as I can't successfully run Firefox 26 (more on this in > separate bugs). I've just committed spidermonkey-24.2.0 to the tree, and I put back the ~ia64 keyword. Please test, if all is good then I'll close the bug.
(In reply to Ian Stakenvicius from comment #5) > (In reply to Émeric Maschino from comment #4) > > Spidermonkey's versioning now matches that of the rest of Mozilla's > products; specifically, each ESR release of Firefox et. al. (so 17.x, 24.x, > etc) will be accompanied by a spidermonkey release of the same version. OK, thanks for this clarification. > I've just committed spidermonkey-24.2.0 to the tree, and I > put back the ~ia64 keyword. Please test, if all is good then I'll close the > bug. I wish I could, but polkit-112[-r1] has RDEPEND="ia64? ( =dev-lang/spidermonkey-1.8.5*[-debug] ) ... !ia64? ( !mips? ( dev-lang/spidermonkey:17[-debug] ) ) that prevents me from emerging spidermonkey-24.2.0 on ia64. Émeric
(In reply to Émeric Maschino from comment #6) > > I've just committed spidermonkey-24.2.0 to the tree, and I > > put back the ~ia64 keyword. Please test, if all is good then I'll close the > > bug. > > I wish I could, but polkit-112[-r1] has > > RDEPEND="ia64? ( =dev-lang/spidermonkey-1.8.5*[-debug] ) > ... > !ia64? ( !mips? ( dev-lang/spidermonkey:17[-debug] ) ) > > that prevents me from emerging spidermonkey-24.2.0 on ia64. > > Émeric Spidermonkey, from version 17 onwards, are in their own slot, so this shouldn't actually get in the way. Also, spidermonkey-24 will not support polkit until there's a version of polkit that has been ported to the sm24 API. 'emerge dev-lang/spidermonkey:24' should work for you, for testing, and you will have a 'js24' binary installed so long as USE="-minimal" to check if it segfaults or not.
(In reply to Ian Stakenvicius from comment #7) > > 'emerge > dev-lang/spidermonkey:24' should work for you, for testing, and you will > have a 'js24' binary installed so long as USE="-minimal" to check if it > segfaults or not. Though spidermonkey:24 was successfully emerged and js24 run flawlessly, re-emerging it with tests enabled failed in: testTrap_gc make: *** [check] Segmentation fault I don't know if tests pass successfully on other arches, so don't know if we must assume that JS is still broken on ia64 or not. Émeric
tests do pass normally, so it's possible that there are still bugs related to ia64. However given that in normal operation things seem to at least work now, I feel comfortable keeping ~ia64 in KEYWORDS. Along these lines, I have committed spidermonkey-17.0.0-r2 containing a backport of the patch from the aforementioned mozilla bug. Please test; if this one is OK (at least when tests are restricted), then we can adjust polkit's dependencies appropriately too.
(In reply to Émeric Maschino from comment #8) > > testTrap_gc > make: *** [check] Segmentation fault I can't identify the particular test this error is occurring on; could you attach the full build.log, or at least everything after the '>>> Source compiled.' line?
Ian, (In reply to Ian Stakenvicius from comment #9) > Along these lines, I have committed spidermonkey-17.0.0-r2 containing a > backport of the patch from the aforementioned mozilla bug. Please test; if > this one is OK (at least when tests are restricted), then we can adjust > polkit's dependencies appropriately too. I can only find spidermonkey-17.0.0-r1, not r2. Emeric
Created attachment 367594 [details] Compressed build.log of spiderdmonkey:24 failing test suite
(In reply to Ian Stakenvicius from comment #10) > (In reply to Émeric Maschino from comment #8) > > > > testTrap_gc > > make: *** [check] Segmentation fault > > I can't identify the particular test this error is occurring on; could you > attach the full build.log, or at least everything after the '>>> Source > compiled.' line? Sure, please find it in attachment #367594 [details]. BTW, the failing test seems to be js/src/jsapi-tests/testTrap.{h|cpp} Emeric
(In reply to Émeric Maschino from comment #13) > (In reply to Ian Stakenvicius from comment #10) > > (In reply to Émeric Maschino from comment #8) > > > > > > testTrap_gc > > > make: *** [check] Segmentation fault > > > > I can't identify the particular test this error is occurring on; could you > > attach the full build.log, or at least everything after the '>>> Source > > compiled.' line? > > Sure, please find it in attachment #367594 [details]. > > BTW, the failing test seems to be js/src/jsapi-tests/testTrap.{h|cpp} > > Emeric Thanks, found it. Unfortunately, there doesn't seem to be anything in that test which is out of the ordinary (ie, would be doing anything that should get patched). As such, I think this patch (and version 24) still need some work. I've now got access to an ia64 dev machine for testing, so hopefully I can have this sorted out soon.
Right.. spidermonkey 17 still segfaults after the patch; no point committing it to the tree until it actually works. Sorry, this may take some time..
Just for kicks, I tried building spidermonkey out of the firefox-26 tree too; it also fails tests in the exact same way. So, although spidermonkey-17 and up still seem to have issues, do we want to put it in the tree anyways for ia64 and let polkit etc try and use it? Maybe nobody will run into the specific issues that trigger these failures in the wild? (not that I actually believe that, but it's possible)
(In reply to Ian Stakenvicius from comment #16) > Just for kicks, I tried building spidermonkey out of the firefox-26 tree > too; it also fails tests in the exact same way. > > So, although spidermonkey-17 and up still seem to have issues, do we want to > put it in the tree anyways for ia64 and let polkit etc try and use it? > Maybe nobody will run into the specific issues that trigger these failures > in the wild? > > (not that I actually believe that, but it's possible) I've double-checked with stable sm-1.8.5-r4, emerging with tests enabled. Guess what? It also fail in the same test with more detailed informations that might give us a starting point for debugging further sm-17, sm-24 and sm-26: testTrap_gc testTrap.cpp:73:CHECK failed: emptyTrapCallCount == 11 TEST-UNEXPECTED-FAIL | testTrap_gc | CHECK failed: emptyTrapCallCount == 11 BTW, sm-1.8.5-r4 was also failing in several other tests, while being keyworded ia64 stable ;-) bug438633_JS_CompileFileHandleForPrincipals :1:InternalError: allocation size overflow testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &r esult) TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFileHandleForPrincipals | CHECK faile d: JS_ExecuteScript(cx, global, scriptObj, &result) [...] bug438633_JS_CompileFileHandle temporary file:1:InternalError: allocation size overflow testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &r esult) TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFileHandle | CHECK failed: JS_Execute Script(cx, global, scriptObj, &result) [...] bug438633_JS_CompileFile :1:InternalError: allocation size overflow testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &r esult) TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFile | CHECK failed: JS_ExecuteScript (cx, global, scriptObj, &result) bug438633_JS_CompileUCScriptForPrincipals :79:InternalError: allocation size overflow testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &r esult) TEST-UNEXPECTED-FAIL | bug438633_JS_CompileUCScriptForPrincipals | CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &result) bug438633_JS_CompileUCScript_empty TEST-PASS | bug438633_JS_CompileUCScript_empty | ok bug438633_JS_CompileUCScript :63:InternalError: allocation size overflow testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, scriptObj, &r esult) TEST-UNEXPECTED-FAIL | bug438633_JS_CompileUCScript | CHECK failed: JS_ExecuteSc ript(cx, global, scriptObj, &result) [...] testIntString_bug515273 testIntString.cpp:14:CHECK failed: JSString::isStatic(str) TEST-UNEXPECTED-FAIL | testIntString_bug515273 | CHECK failed: JSString::isStati c(str) [...] testConservativeGC.cpp:77:CHECK failed: !memcmp(ch, expected, sizeof(expected)) TEST-UNEXPECTED-FAIL | testDerivedValues | CHECK failed: !memcmp(ch, expected, s izeof(expected)) I don't know how do you want to deal with this, but at the moment, the only Firefox version that can be emerged and seems to work flawlessly on ia64 since ESR 10 is 26. And I don't seem to have more issues with Firefox 26 than with ESR 10. In fact, I never got a crash/problem now that I'm using it for 5 days [1]. Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=497516#c6
(In reply to Émeric Maschino from comment #17) > (In reply to Ian Stakenvicius from comment #16) > > Just for kicks, I tried building spidermonkey out of the firefox-26 tree > > too; it also fails tests in the exact same way. > > > > So, although spidermonkey-17 and up still seem to have issues, do we want to > > put it in the tree anyways for ia64 and let polkit etc try and use it? > > Maybe nobody will run into the specific issues that trigger these failures > > in the wild? > > > > (not that I actually believe that, but it's possible) > > I've double-checked with stable sm-1.8.5-r4, emerging with tests enabled. > Guess what? It also fail in the same test with more detailed informations > that might give us a starting point for debugging further sm-17, sm-24 and > sm-26: > > testTrap_gc > testTrap.cpp:73:CHECK failed: emptyTrapCallCount == 11 > TEST-UNEXPECTED-FAIL | testTrap_gc | CHECK failed: emptyTrapCallCount == 11 > > BTW, sm-1.8.5-r4 was also failing in several other tests, while being > keyworded ia64 stable ;-) > > bug438633_JS_CompileFileHandleForPrincipals > :1:InternalError: allocation size overflow > testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, > scriptObj, &r > esult) > TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFileHandleForPrincipals | CHECK > faile > d: JS_ExecuteScript(cx, global, scriptObj, &result) > > [...] > > bug438633_JS_CompileFileHandle > temporary file:1:InternalError: allocation size overflow > testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, > scriptObj, &r > esult) > TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFileHandle | CHECK failed: > JS_Execute > Script(cx, global, scriptObj, &result) > > [...] > > bug438633_JS_CompileFile > :1:InternalError: allocation size overflow > testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, > scriptObj, &r > esult) > TEST-UNEXPECTED-FAIL | bug438633_JS_CompileFile | CHECK failed: > JS_ExecuteScript > (cx, global, scriptObj, &result) > bug438633_JS_CompileUCScriptForPrincipals > :79:InternalError: allocation size overflow > testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, > scriptObj, &r > esult) > TEST-UNEXPECTED-FAIL | bug438633_JS_CompileUCScriptForPrincipals | CHECK > failed: > JS_ExecuteScript(cx, global, scriptObj, &result) > bug438633_JS_CompileUCScript_empty > TEST-PASS | bug438633_JS_CompileUCScript_empty | ok > bug438633_JS_CompileUCScript > :63:InternalError: allocation size overflow > testScriptObject.cpp:26:CHECK failed: JS_ExecuteScript(cx, global, > scriptObj, &r > esult) > TEST-UNEXPECTED-FAIL | bug438633_JS_CompileUCScript | CHECK failed: > JS_ExecuteSc > ript(cx, global, scriptObj, &result) > > [...] > > testIntString_bug515273 > testIntString.cpp:14:CHECK failed: JSString::isStatic(str) > TEST-UNEXPECTED-FAIL | testIntString_bug515273 | CHECK failed: > JSString::isStati > c(str) > > [...] > > testConservativeGC.cpp:77:CHECK failed: !memcmp(ch, expected, > sizeof(expected)) > TEST-UNEXPECTED-FAIL | testDerivedValues | CHECK failed: !memcmp(ch, > expected, s > izeof(expected)) > > I don't know how do you want to deal with this, but at the moment, the only > Firefox version that can be emerged and seems to work flawlessly on ia64 > since ESR 10 is 26. And I don't seem to have more issues with Firefox 26 > than with ESR 10. In fact, I never got a crash/problem now that I'm using it > for 5 days [1]. > > Émeric > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=497516#c6 OK. So, i tried building spidermonkey out of the firefox-26 tree, and it failed the exact same way. Pairing this with the fact that old spidermonkeys also failed this way, leads me to think maybe it's worth taking a chance on spidermonkey-17. Committing now, with tests restricted for ia64.
Is this solved then? *spidermonkey-17.0.0-r2 (20 Jan 2014) 20 Jan 2014; Ian Stakenvicius <axs@gentoo.org> +files/spidermonkey-17-ia64-mmap.patch, +spidermonkey-17.0.0-r2.ebuild: backport mmap patch to fix ia64 on spidermonkey-17
(In reply to Pacho Ramos from comment #19) > Is this solved then? > *spidermonkey-17.0.0-r2 (20 Jan 2014) > > 20 Jan 2014; Ian Stakenvicius <axs@gentoo.org> > +files/spidermonkey-17-ia64-mmap.patch, +spidermonkey-17.0.0-r2.ebuild: > backport mmap patch to fix ia64 on spidermonkey-17 Nice, spidermonkey-17.0.0-r2 emerged successfully, including tests :-) Émeric
Nice news :D, thanks a lot!
(In reply to Émeric Maschino from comment #20) > (In reply to Pacho Ramos from comment #19) > > Is this solved then? > > *spidermonkey-17.0.0-r2 (20 Jan 2014) > > > > 20 Jan 2014; Ian Stakenvicius <axs@gentoo.org> > > +files/spidermonkey-17-ia64-mmap.patch, +spidermonkey-17.0.0-r2.ebuild: > > backport mmap patch to fix ia64 on spidermonkey-17 > > Nice, spidermonkey-17.0.0-r2 emerged successfully, including tests :-) > > Émeric I've done the same tests restriction for ia64 on sm24 now, too. Thanks for testing!!
