Bug 971519 - Immediate SEGV in test suite
Immediate SEGV in test suite
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mozjs17 (Show other bugs)
19
ppc Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
AcceptedFreezeException
: Reopened
Depends On:
Blocks: F19-accepted/F19FinalFreezeException 971046
  Show dependency treegraph
 
Reported: 2013-06-06 13:28 EDT by Miloslav Trmač
Modified: 2014-01-05 19:36 EST (History)
5 users (show)

See Also:
Fixed In Version: mozjs17-17.0.0-7.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-23 02:26:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Run the test suite in %check (450 bytes, patch)
2013-06-06 15:01 EDT, Miloslav Trmač
walters: review+
Details | Diff
Support 64k pages (1.13 KB, patch)
2013-06-06 15:03 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description Miloslav Trmač 2013-06-06 13:28:44 EDT
After adding
> %check
> make -C js/src check
to the spec file, the test suite fails on ppc and ppc64 without outputting any test resuts:
> ../dist/bin/jsapi-tests
> make[1]: *** [check] Segmentation fault (core dumped)

(it passes on my local x86_64 build; doing a Koji i386 and x86_64 build right now, will update with results later).

This might be the cause of #971046, polkit segfaulting during installation (note that this is just a guess without actually establishing the cause).
Comment 2 Miloslav Trmač 2013-06-06 13:34:07 EDT
(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.
Comment 3 Miloslav Trmač 2013-06-06 14:14:18 EDT
BTW, please add the %check to the spec file in any case, to avoid surprises.
Comment 4 Miloslav Trmač 2013-06-06 14:23:44 EDT
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
Comment 5 Miloslav Trmač 2013-06-06 15:01:39 EDT
Created attachment 757827 [details]
Run the test suite in %check
Comment 6 Miloslav Trmač 2013-06-06 15:03:48 EDT
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.
Comment 7 Miloslav Trmač 2013-06-06 15:11:01 EDT
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 8 Colin Walters 2013-06-07 12:42:03 EDT
Comment on attachment 757827 [details]
Run the test suite in %check

Looks fine, please commit.
Comment 9 Gustavo Luiz Duarte 2013-06-07 15:27:38 EDT
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.
Comment 10 Colin Walters 2013-06-07 17:28:12 EDT
(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?
Comment 11 Gustavo Luiz Duarte 2013-06-07 17:54:41 EDT
> 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
Comment 12 Colin Walters 2013-06-07 18:22:01 EDT
(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
Comment 13 Matthias Clasen 2013-06-08 10:05:16 EDT
We need this in f19 too, I think ?
One of the dependent bugs is an f19 blocker...
Comment 14 Fedora Update System 2013-06-10 14:01:29 EDT
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
Comment 15 Fedora Update System 2013-06-11 13:53:20 EDT
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).
Comment 16 Fedora Update System 2013-06-13 02:41:39 EDT
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.
Comment 17 Dennis Gilmore 2013-06-15 12:10:33 EDT
/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
Comment 18 Colin Walters 2013-06-17 12:14:19 EDT
(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?
Comment 19 Dennis Gilmore 2013-06-17 13:12:38 EDT
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
Comment 20 Colin Walters 2013-06-17 13:25:38 EDT
(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.
Comment 21 Fedora Update System 2013-06-17 16:44:53 EDT
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
Comment 22 Adam Williamson 2013-06-17 17:08:26 EDT
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.
Comment 23 Fedora Update System 2013-06-18 15:39:04 EDT
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).
Comment 24 Fedora Update System 2013-06-23 02:26:21 EDT
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.
Comment 25 Ingvar Hagelund 2013-08-27 18:52:48 EDT
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
Comment 26 Ingvar Hagelund 2014-01-05 19:36:48 EST
Revisited on fedora 20, 32bit ppc. polkitd and upowerd segfaults. Rebuilding mozjs17 without the patch makes polkitd and upowerd work properly again.

Note You need to log in before you can comment on or make changes to this bug.