See http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1702/1151702/build.log and http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1703/1151703/build.log for full (scratch) build logs.

(In reply to Miloslav Trmač from comment #0)
> (it passes on my local x86_64 build; doing a Koji i386 and x86_64 build
> right now, will update with results later).
All tests pass on i386 and x86_64.

BTW, please add the %check to the spec file in any case, to avoid surprises.

Running polkitd in a f19 mock crashes with:
> #0  0x00003fffb79706e8 in js::gc::InitMemorySubsystem () at /usr/src/debug/mozjs17.0.0/js/src/gc/Memory.cpp:306
> #1  0x00003fffb771eee4 in JS_Init (maxbytes=<optimized out>) at /usr/src/debug/mozjs17.0.0/js/src/jsapi.cpp:1057
> #2  0x0000000050320298 in 000000a7.plt_call.polkit_subject_get_type ()
> #3  0x00003fffb7c96614 in .g_object_newv () from /lib64/libgobject-2.0.so.0
> #4  0x00003fffb7c96e70 in .g_object_new () from /lib64/libgobject-2.0.so.0
> #5  0x000000005031d898 in .polkit_backend_authority_get ()
> #6  0x000000005031b75c in .main ()

with #0 being
> 302	void
> 303	InitMemorySubsystem()
> 304	{
> 305	    if (size_t(sysconf(_SC_PAGESIZE)) != PageSize)
> 306	        MOZ_CRASH();
> 307	}
and
> (gdb) call sysconf(_SC_PAGESIZE)
> $2 = 65536
> (gdb) p PageSize
> $3 = 4096

Created attachment 757827 [details]
Run the test suite in %check

Created attachment 757838 [details]
Support 64k pages

This is based on the conditionals in http://pkgs.fedoraproject.org/cgit/xulrunner.git/tree/rhbz-911314.patch .

Honestly, I have absolutely no idea what I'm doing but the test suite seems to pass with this patch (and polkit doesn't crash, though I haven't really tested that it works :) ).

A more detailed review of the code by somebody familiar with SpiderMonkey would definitely be helpful.

On second thought... the test suite failed on ppc(32-bit) as well, but the patch above deals only with ppc64.

Colin, can you look at that case yourself, please?

Comment on attachment 757827 [details]
Run the test suite in %check

Looks fine, please commit.

Please use this patch: http://pkgs.fedoraproject.org/cgit/xulrunner.git/plain/mozilla-746112.patch?h=f17&id=8fc9b34d912bd0b08a215876f8280ad453b1dcb8

This is more complete than the patch from comment #6. Only adjusting the page and arena sizes is not enough because you will hit runtime issues in the decommit code. This patch is based on Terrence's patch posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=746112#c25

I tested mozjs17 with this patch and it built and passed all tests for both ppc64 and ppc32.

(In reply to Gustavo Luiz Duarte from comment #9)
> This patch is based on Terrence's patch posted here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=746112#c25

Who modified it and why?  I added the upstream Mercurial commit data to this patch, but I'd appreciate to know why it was further changed.

Comparing the two, it looks mostly cosmetic; upstream has the conditional inside the decommit code, xulrunner patch only calls them conditionally.  But why?

> Who modified it and why?  I added the upstream Mercurial commit data to this
> patch, but I'd appreciate to know why it was further changed.
> 
> Comparing the two, it looks mostly cosmetic; upstream has the conditional
> inside the decommit code, xulrunner patch only calls them conditionally. 
> But why?

I got the original patch from Terrence and adapted to Mozilla17. But prior to committing to the upstream Mercurial, Terrence applied Bill's suggestion: https://bugzilla.mozilla.org/show_bug.cgi?id=746112#c26

That is why the upstream commit has the condition inside MarkPagesUnused() instead of conditionally calling it. However, although it looks mostly cosmetic, this change has side effects. See comments #7 and #8 from https://bugzilla.mozilla.org/show_bug.cgi?id=840242

Basically, MarkPagesUnused() will fail instead of silently not being called. This generates an infinite loop, as described here: https://bugzilla.mozilla.org/show_bug.cgi?id=840242#c5

(In reply to Gustavo Luiz Duarte from comment #11)
>
> Basically, MarkPagesUnused() will fail instead of silently not being called.
> This generates an infinite loop, as described here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=840242#c5

Thanks for the explanation!  Building in rawhide:
http://pkgs.fedoraproject.org/cgit/mozjs17.git/commit/?id=f8252f7999164d97d82a40b6461b447196cc5da4
http://koji.fedoraproject.org/koji/taskinfo?taskID=5482168

We need this in f19 too, I think ?
One of the dependent bugs is an f19 blocker...

mozjs17-17.0.0-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mozjs17-17.0.0-6.fc19

Package mozjs17-17.0.0-6.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mozjs17-17.0.0-6.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10533/mozjs17-17.0.0-6.fc19
then log in and leave karma (feedback).

mozjs17-17.0.0-6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

/builddir/build/BUILD/mozjs17.0.0/js/src/config/find_vanilla_new_calls libjs_static.a libjs_static.a.desc
TEST-UNEXPECTED-FAIL | find_vanilla_new_calls | found calls are listed below
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
         U operator new(unsigned int)
make: Leaving directory `/builddir/build/BUILD/mozjs17.0.0/js/src'
make: *** [check-vanilla-new] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.zgMSMn (%check)

test suite fails on arm arches

(In reply to Dennis Gilmore from comment #17)
> /builddir/build/BUILD/mozjs17.0.0/js/src/config/find_vanilla_new_calls
> libjs_static.a libjs_static.a.desc
> TEST-UNEXPECTED-FAIL | find_vanilla_new_calls | found calls are listed below


Is this the only test that fails?  In other words if you add "exit 0" to the top of js/src/config/find_vanilla_new_calls, does %check succeed?

i applied the following patch and did a scratch build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1925589

build completed fine. so yes its the only test failing

diff --git a/mozjs17.spec b/mozjs17.spec
index fc8242d..2d61712 100644
--- a/mozjs17.spec
+++ b/mozjs17.spec
@@ -49,6 +49,10 @@ chmod a+x configure
 make %{?_smp_mflags}
 
 %check
+cat > js/src/config/find_vanilla_new_calls << EOF
+#!/bin/bash
+exit 0
+EOF
 make -C js/src check
 
 %install

(In reply to Dennis Gilmore from comment #19)
> i applied the following patch and did a scratch build
> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1925589
> 
> build completed fine. so yes its the only test failing

Ok, let's just disable this test on all architectures for now; it looks fairly bogus to me at first glance, but I will investigate more closely soon.

mozjs17-17.0.0-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mozjs17-17.0.0-7.fc19

Marking this as an FE explicitly - it should be inherited from 971046 but it's not showing in the list and we want to make sure we pull this fix in future builds.

Package mozjs17-17.0.0-7.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mozjs17-17.0.0-7.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11139/mozjs17-17.0.0-7.fc19
then log in and leave karma (feedback).

mozjs17-17.0.0-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

That patch breaks 32bit ppc (at least on my system). polkitd and upowerd segfaults. Rebuilding mozjs17 without the patch makes polkitd and upowerd work properly again.

make check fails on a few tests, though. I can send the fail log to anyone interested.

Ingvar

Revisited on fedora 20, 32bit ppc. polkitd and upowerd segfaults. Rebuilding mozjs17 without the patch makes polkitd and upowerd work properly again.