Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2019-02-05 Thread Simon McVittie
On Mon, 24 Sep 2018 at 21:18:47 +0100, Simon McVittie wrote:
> Most of the test cases provided with mozjs60 crash:
> 
> grep '^TEST-' s390x.log | cut -d' ' -f1 | sort | uniq -c
>1714 TEST-KNOWN-FAIL
>6923 TEST-PASS
>   28635 TEST-UNEXPECTED-FAIL

This seems to be endianness-related (works on 32-bit and on little-endian, but
is broken on 64-bit big-endian) so perhaps PowerPC porters would be interested
in helping here?

Upstream bug: https://bugzilla.mozilla.org/1488552

My best attempt at backporting fixes (still fails many tests on s390x):
https://salsa.debian.org/gnome-team/mozjs60/merge_requests/1

I've got as far as I can with this and would really appreciate a porter
or a Mozilla expert taking over.

Note that any patches proposed for this should also be tested on 32-bit BE
(mips or powerpc) since it looks as though the patches that were applied
upstream are probably going to break those.

smcv



Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-11-03 Thread Simon McVittie
Control: severity -1 important

On Mon, 24 Sep 2018 at 21:18:47 +0100, Simon McVittie wrote:
> We can't upgrade gjs to a version that uses mozjs60 until either this is
> fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
> removed from s390x. The architecture-specific removal seems a more likely
> short term solution; if this is done I'll downgrade this bug to important.

Doing so now.

smcv



Bug#906016: Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-10-04 Thread Simon McVittie
On Thu, 04 Oct 2018 at 11:24:14 +0200, Philipp Kern wrote:
> Running the revdep check for gjs (there are currently none on mozjs60):
> > Checking reverse dependencies...
> > # Broken Depends:
> > gnome-characters: gnome-characters
> > gnome-documents: gnome-documents
> > gnome-maps: gnome-maps
> > gnome-shell: gnome-shell
> > gnome-sound-recorder: gnome-sound-recorder
> > gnome-sushi: gnome-sushi
> > gnome-weather: gnome-weather
> > ostree: ostree-tests
> > polari: polari
> > 
> > # Broken Build-Depends:
> > gnome-characters: gjs (>= 1.49)
> >   libgjs-dev (>= 1.49)
> > gnome-documents: gjs (>= 1.48.0)
> >  libgjs-dev (>= 1.48)
> > gnome-maps: gjs (>= 1.50.0)
> > libgjs-dev (>= 1.44.0)
> > gnome-shell: libgjs-dev (>= 1.50.2-3~)
> > gnome-sound-recorder: gjs
> > gnome-sushi: libgjs-dev (>= 1.40)
> > gnome-weather: gjs (>= 1.49.4)
> >libgjs-dev (>= 1.39.91)
> > gpaste: libgjs-dev (>= 1.48.0)
> > libguestfs: gjs
> > libsecret: gjs
> > polari: libgjs-dev (>= 1.49.2)
> > seed-webkit2: libgjs-dev
> > 
> > Dependency problem found.
> 
> The main packages that are regrettable in this context are libguestfs
> and maybe also ostree. Would the gjs dependency be avoidable there?

I think we'll probably also want libsecret to survive, but that was
already fixed in unstable. (Maybe it showed up in your search as a result
of outdated binary packages on some architecture?)

ostree is fixed in git, I'll upload that soon: https://bugs.debian.org/910286

I've sent a patch for libguestfs, which is not a GNOME team package:
https://bugs.debian.org/910287

Both are marked as blockers for the transition bug
.

smcv



Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-10-04 Thread Simon McVittie
On Thu, 04 Oct 2018 at 11:24:14 +0200, Philipp Kern wrote:
> The main packages that are regrettable in this context are libguestfs
> and maybe also ostree. Would the gjs dependency be avoidable there?

ostree: definitely OK, the necessary changes are already staged
in git. gjs is only used for one test, which can be skipped on
non-mozjs-capable architectures.

libguestfs: it looks as though the B-D is for build-time tests of
GObject-Introspection bindings, which can be skipped (at a loss of
coverage).

smcv



Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-10-04 Thread Philipp Kern
On 24.09.2018 22:18, Simon McVittie wrote:
> We can't upgrade gjs to a version that uses mozjs60 until either this is
> fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
> removed from s390x. The architecture-specific removal seems a more likely
> short term solution; if this is done I'll downgrade this bug to important.

Running the revdep check for gjs (there are currently none on mozjs60):

> % dak rm -n -a s390x -R gjs
> W: -a/--architecture implies -p/--partial.
> Will remove the following packages from unstable:
> 
>gjs |   1.50.2-1 | source
>gjs |   1.52.3-2 | source, s390x
>  gjs-tests |   1.52.3-2 | s390x
> libgjs-dev |   1.52.3-2 | s390x
>   libgjs0g |   1.52.3-2 | s390x
> 
> Maintainer: Debian GNOME Maintainers 
> 
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> # Broken Depends:
> gnome-characters: gnome-characters
> gnome-documents: gnome-documents
> gnome-maps: gnome-maps
> gnome-shell: gnome-shell
> gnome-sound-recorder: gnome-sound-recorder
> gnome-sushi: gnome-sushi
> gnome-weather: gnome-weather
> ostree: ostree-tests
> polari: polari
> 
> # Broken Build-Depends:
> gnome-characters: gjs (>= 1.49)
>   libgjs-dev (>= 1.49)
> gnome-documents: gjs (>= 1.48.0)
>  libgjs-dev (>= 1.48)
> gnome-maps: gjs (>= 1.50.0)
> libgjs-dev (>= 1.44.0)
> gnome-shell: libgjs-dev (>= 1.50.2-3~)
> gnome-sound-recorder: gjs
> gnome-sushi: libgjs-dev (>= 1.40)
> gnome-weather: gjs (>= 1.49.4)
>libgjs-dev (>= 1.39.91)
> gpaste: libgjs-dev (>= 1.48.0)
> libguestfs: gjs
> libsecret: gjs
> polari: libgjs-dev (>= 1.49.2)
> seed-webkit2: libgjs-dev
> 
> Dependency problem found.

The main packages that are regrettable in this context are libguestfs
and maybe also ostree. Would the gjs dependency be avoidable there?

Kind regards
Philipp Kern



Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-10-03 Thread Julien Cristau
Control: forwarded -1 https://bugzilla.mozilla.org/1488552

On 10/03/2018 11:48 AM, Julien Cristau wrote:
> However the below remains, and was also hit by someone from SuSE:
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/wen_xnpCdfo/fU-Ze7QXAwAJ
> 
Linking the related bugzilla entry.

Cheers,
Julien



Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-10-03 Thread Julien Cristau
On 09/24/2018 10:18 PM, Simon McVittie wrote:
> % gdb /home/smcv/mozjs60/debian/build/dist/bin/js js/src/tests/core
> Core was generated by `/home/smcv/mozjs60/debian/build/dist/bin/js -f 
> shell.js -f test262/shell.js -f'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ContextToPC (context=0x3fff7e7d740) at 
> ./js/src/wasm/WasmSignalHandlers.cpp:452
> 452 MOZ_CRASH();
> [Current thread is 1 (Thread 0x3ffad574750 (LWP 63693))]
> Loading JavaScript value pretty-printers; see js/src/gdb/README.
> If they cause trouble, type: disable pretty-printer .* SpiderMonkey
> SpiderMonkey unwinder is disabled by default, to enable it type:
> enable unwinder .* SpiderMonkey
> (gdb) bt
> #0  0x000112a11e96 in ContextToPC (context=0x3fff7e7d740) at 
> ./js/src/wasm/WasmSignalHandlers.cpp:452
> #1  0x000112a11e96 in HandleFault (info=0x3fff7e7d6c0, ctx=0x3fff7e7d740, 
> signum=)
> at ./js/src/wasm/WasmSignalHandlers.cpp:1399
> #2  0x000112a11e96 in WasmFaultHandler(int, siginfo_t*, void*) 
> (signum=, info=0x3fff7e7d6c0, context=0x3fff7e7d740) at 
> ./js/src/wasm/WasmSignalHandlers.cpp:1477

The above bits can be avoided with the patch from
https://bugzilla.mozilla.org/1464751.

However the below remains, and was also hit by someone from SuSE:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/wen_xnpCdfo/fU-Ze7QXAwAJ

I wouldn't hold out much hope of a quick fix, so removal on s390x makes
sense to me.

> #3  0x03fff7e7d6b8 in  ()
> #4  0x000112aa6f04 in 
> js::ProtectedData, unsigned 
> int>::operator++(int) (this=0x7b0) at ./js/src/threading/ProtectedData.h:95
> #5  0x000112aa6f04 in js::TenuringTracer::moveToTenured(JSString*) 
> (this=0x3fff7e7dde8, src=Python Exception  
> 'ascii' codec can't encode characters in position 3-4: ordinal not in 
> range(128):
> )
> at ./js/src/gc/Marking.cpp:3226
> #6  0x000112aa70d2 in js::TenuringTracer::traverse(JSString**) 
> (this=this@entry=0x3fff7e7dde8, strp=0x11a89d598) at 
> ./js/src/gc/Marking.cpp:2743
> #7  0x000112ab2d68 in 
> js::gc::StoreBuffer::CellPtrEdge::trace(js::TenuringTracer&) const 
> (this=this@entry=0x11a608e58, mover=...) at ./js/src/gc/Marking.cpp:2919
> #8  0x000112ab2da8 in 
> js::gc::StoreBuffer::MonoTypeBuffer::trace(js::gc::StoreBuffer*,
>  js::TenuringTracer&) (this=this@entry=0x11a608e40, owner= variable: value has been optimized out>, mover=...) at 
> ./js/src/gc/StoreBuffer.h:236
> #9  0x000112ac8c00 in 
> js::gc::StoreBuffer::traceCells(js::TenuringTracer&) (mover=..., 
> this=)
> at ./js/src/gc/StoreBuffer.h:440
> #10 0x000112ac8c00 in js::Nursery::doCollection(JS::gcreason::Reason, 
> js::gc::TenureCountCache&) (this=this@entry=0x11a608af8, 
> reason=reason@entry=315707392, tenureCounts=...) at 
> ./js/src/gc/Nursery.cpp:858
> #11 0x000112ac9ffa in js::Nursery::collect(JS::gcreason::Reason) 
> (this=this@entry=0x11a608af8, 
> reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at 
> ./js/src/gc/Nursery.cpp:724
> #12 0x000112a79f76 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
> js::gcstats::PhaseKind) (this=this@entry=0x11a6069a8, 
> reason=reason@entry=JS::gcreason::DESTROY_RUNTIME, 
> phase=phase@entry=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC) at 
> ./js/src/threading/ProtectedData.h:98
> #13 0x000112a9f340 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
> js::gcstats::PhaseKind) 
> (phase=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC, 
> reason=JS::gcreason::DESTROY_RUNTIME, this=0x11a6069a8)
> at ./debian/build/dist/include/mozilla/ThreadLocal.h:223
> #14 0x000112a9f340 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, 
> JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
> nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
> reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7365
> #15 0x000112a9f73e in js::gc::GCRuntime::collect(bool, js::SliceBudget, 
> JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
> nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
> reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7556
> #16 0x000112a9f8ac in js::gc::GCRuntime::gc(JSGCInvocationKind, 
> JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
> gckind=gckind@entry=GC_NORMAL, 
> reason=reason@entry=JS::gcreason::DESTROY_RUNTIME)
> at ./debian/build/dist/include/js/SliceBudget.h:61
> #17 0x0001128e415c in JSRuntime::destroyRuntime() (this=0x11a6064b0) at 
> ./js/src/vm/Runtime.cpp:316
> #18 0x000112875b82 in js::DestroyContext(JSContext*) (cx=0x11a60b130) at 
> ./js/src/vm/JSContext.h:305
> #19 0x00011242fb1e in main(int, char**, char**) (argc=, 
> argv=, envp=) at ./js/src/shell/js.cpp:9431
> 

For some more context, with a SEGV at ./js/src/gc/Marking.cpp:3226:

(gdb) list
3221MOZ_ASSERT(IsInsideNursery(src));
3222MOZ_ASSERT(!src->zone()->usedByHelperThread());
3223
3224AllocKind 

Bug#909536: mozjs60: FTBFS on s390x: around 80% of tests crash

2018-09-24 Thread Simon McVittie
Source: mozjs60
Version: 60.2.1-1
Severity: serious
Tags: ftbfs help
X-Debbugs-Cc: debian-s...@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x

Most of the test cases provided with mozjs60 crash:

grep '^TEST-' s390x.log | cut -d' ' -f1 | sort | uniq -c
   1714 TEST-KNOWN-FAIL
   6923 TEST-PASS
  28635 TEST-UNEXPECTED-FAIL

See 
https://buildd.debian.org/status/fetch.php?pkg=mozjs60=s390x=60.2.1-1=1537442189=0
for a full log. You'll see that the result of many tests is "rc = -11"
(I think that's signal 11, or SIGSEGV).

After reproducing this on the porterbox zelenka, a backtrace from one
such crash is below. The js interpreter seems to be crashing during a
garbage collection pass triggered during process shutdown.

This is a regression since mozjs52, in which only a few tests failed
(#878286). I'm willing to ignore a few isolated test failures, but when
80% of the tests fail, I don't think we can be confident that mozjs60
is at all usable on s390x.

We can't upgrade gjs to a version that uses mozjs60 until either this is
fixed somehow, or gjs and its dependencies (notably GNOME Shell) are
removed from s390x. The architecture-specific removal seems a more likely
short term solution; if this is done I'll downgrade this bug to important.

Thanks,
smcv

% gdb /home/smcv/mozjs60/debian/build/dist/bin/js js/src/tests/core
Core was generated by `/home/smcv/mozjs60/debian/build/dist/bin/js -f shell.js 
-f test262/shell.js -f'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ContextToPC (context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:452
452 MOZ_CRASH();
[Current thread is 1 (Thread 0x3ffad574750 (LWP 63693))]
Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
SpiderMonkey unwinder is disabled by default, to enable it type:
enable unwinder .* SpiderMonkey
(gdb) bt
#0  0x000112a11e96 in ContextToPC (context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:452
#1  0x000112a11e96 in HandleFault (info=0x3fff7e7d6c0, ctx=0x3fff7e7d740, 
signum=)
at ./js/src/wasm/WasmSignalHandlers.cpp:1399
#2  0x000112a11e96 in WasmFaultHandler(int, siginfo_t*, void*) 
(signum=, info=0x3fff7e7d6c0, context=0x3fff7e7d740) at 
./js/src/wasm/WasmSignalHandlers.cpp:1477
#3  0x03fff7e7d6b8 in  ()
#4  0x000112aa6f04 in 
js::ProtectedData, unsigned 
int>::operator++(int) (this=0x7b0) at ./js/src/threading/ProtectedData.h:95
#5  0x000112aa6f04 in js::TenuringTracer::moveToTenured(JSString*) 
(this=0x3fff7e7dde8, src=Python Exception  'ascii' 
codec can't encode characters in position 3-4: ordinal not in range(128):
)
at ./js/src/gc/Marking.cpp:3226
#6  0x000112aa70d2 in js::TenuringTracer::traverse(JSString**) 
(this=this@entry=0x3fff7e7dde8, strp=0x11a89d598) at 
./js/src/gc/Marking.cpp:2743
#7  0x000112ab2d68 in 
js::gc::StoreBuffer::CellPtrEdge::trace(js::TenuringTracer&) const 
(this=this@entry=0x11a608e58, mover=...) at ./js/src/gc/Marking.cpp:2919
#8  0x000112ab2da8 in 
js::gc::StoreBuffer::MonoTypeBuffer::trace(js::gc::StoreBuffer*,
 js::TenuringTracer&) (this=this@entry=0x11a608e40, owner=, mover=...) at 
./js/src/gc/StoreBuffer.h:236
#9  0x000112ac8c00 in js::gc::StoreBuffer::traceCells(js::TenuringTracer&) 
(mover=..., this=)
at ./js/src/gc/StoreBuffer.h:440
#10 0x000112ac8c00 in js::Nursery::doCollection(JS::gcreason::Reason, 
js::gc::TenureCountCache&) (this=this@entry=0x11a608af8, 
reason=reason@entry=315707392, tenureCounts=...) at ./js/src/gc/Nursery.cpp:858
#11 0x000112ac9ffa in js::Nursery::collect(JS::gcreason::Reason) 
(this=this@entry=0x11a608af8, 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at 
./js/src/gc/Nursery.cpp:724
#12 0x000112a79f76 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
js::gcstats::PhaseKind) (this=this@entry=0x11a6069a8, 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME, 
phase=phase@entry=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC) at 
./js/src/threading/ProtectedData.h:98
#13 0x000112a9f340 in js::gc::GCRuntime::minorGC(JS::gcreason::Reason, 
js::gcstats::PhaseKind) 
(phase=js::gcstats::PhaseKind::EVICT_NURSERY_FOR_MAJOR_GC, 
reason=JS::gcreason::DESTROY_RUNTIME, this=0x11a6069a8)
at ./debian/build/dist/include/mozilla/ThreadLocal.h:223
#14 0x000112a9f340 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, 
JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7365
#15 0x000112a9f73e in js::gc::GCRuntime::collect(bool, js::SliceBudget, 
JS::gcreason::Reason) (this=this@entry=0x11a6069a8, 
nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
reason=reason@entry=JS::gcreason::DESTROY_RUNTIME) at ./js/src/gc/GC.cpp:7556
#16 0x000112a9f8ac in js::gc::GCRuntime::gc(JSGCInvocationKind,