Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread GCS 
On Sun, Jan 15, 2017 at 8:36 PM, James Clarke  wrote:
> On 15 Jan 2017, at 19:32, László Böszörményi (GCS)  wrote:
> Not sure why you listed it as an NMU in d/changelog, given you're the
> maintainer :)
 That's what 'dch -i' gives as default - not changed yet. :)

>> [3] https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb0fe7e92f6
>
> This is the important one. Adrian, is there anything else?
 Did you check all patches in that changeset[1]? All mention Sparc64.

Cheers,
Laszlo/GCS
[1] 
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=f9307a83e555

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread John Paul Adrian Glaubitz 
On 01/15/2017 08:36 PM, James Clarke wrote:
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
>> [2] https://hg.mozilla.org/integration/mozilla-inbound/rev/f9307a83e555
> 
> This one only affects NetBSD. Might as well backport it though.

This is just necessary if mozjs24 uses the incorrect "__sparc64__" to
test for sparc64 instead of the correct "__sparc__" && "__arch64__".

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread James Clarke 
On 15 Jan 2017, at 19:32, László Böszörményi (GCS)  wrote:
> On Sun, Jan 15, 2017 at 7:26 PM, Simon McVittie  wrote:
>> On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
>>> For the time being, Firefox upstream is now using the arm64 workaround on 
>>> sparc64
>>> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 
>>> with
>>> version 53.
>> 
>> Can you point those interested in this bug to a patch/commit/something that
>> describes "the arm64 workaround"? Is it related to #839050?
> I think Adrian refers to the upstream bugreport #1275204 [1] and two
> fixes[2][3]. Any other patches I should backport? I attach a debdiff
> for testing.

Not sure why you listed it as an NMU in d/changelog, given you're the
maintainer :)

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
> [2] https://hg.mozilla.org/integration/mozilla-inbound/rev/f9307a83e555

This one only affects NetBSD. Might as well backport it though.

> [3] https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb0fe7e92f6

This is the important one. Adrian, is there anything else?

Regards,
James

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread GCS 
On Sun, Jan 15, 2017 at 7:26 PM, Simon McVittie  wrote:
> On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
>> For the time being, Firefox upstream is now using the arm64 workaround on 
>> sparc64
>> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
>> version 53.
>
> Can you point those interested in this bug to a patch/commit/something that
> describes "the arm64 workaround"? Is it related to #839050?
 I think Adrian refers to the upstream bugreport #1275204 [1] and two
fixes[2][3]. Any other patches I should backport? I attach a debdiff
for testing.

Regards,
Laszlo/GCS
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
[2] https://hg.mozilla.org/integration/mozilla-inbound/rev/f9307a83e555
[3] https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb0fe7e92f6
diff -Nru mozjs24-24.2.0/debian/changelog mozjs24-24.2.0/debian/changelog
--- mozjs24-24.2.0/debian/changelog	2017-01-07 01:42:14.0 +
+++ mozjs24-24.2.0/debian/changelog	2017-01-15 18:31:03.0 +
@@ -1,3 +1,9 @@
+mozjs24 (24.2.0-6) unstable; urgency=low
+
+  * Non-maintainer upload.
+
+ -- Laszlo Boszormenyi (GCS)   Sun, 15 Jan 2017 18:31:03 +
+
 mozjs24 (24.2.0-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mozjs24-24.2.0/debian/patches/Use_better_pre-processor_defines_for_sparc64.patch mozjs24-24.2.0/debian/patches/Use_better_pre-processor_defines_for_sparc64.patch
--- mozjs24-24.2.0/debian/patches/Use_better_pre-processor_defines_for_sparc64.patch	1970-01-01 00:00:00.0 +
+++ mozjs24-24.2.0/debian/patches/Use_better_pre-processor_defines_for_sparc64.patch	2017-01-15 18:31:03.0 +
@@ -0,0 +1,21 @@
+
+# HG changeset patch
+# User John Paul Adrian Glaubitz 
+# Date 1481559553 -3600
+# Node ID f9307a83e5554072d3bc9167d88562cd5ad131d1
+# Parent  079ab396035168b99837846fa5a67dc540bfbfd9
+Bug 1275204 - js: Use better pre-processor defines for sparc64. r=glandium
+
+
+diff --git a/js/src/gc/Memory.cpp b/js/src/gc/Memory.cpp
+--- a/js/src/gc/Memory.cpp
 b/js/src/gc/Memory.cpp
+@@ -313,7 +313,7 @@ gc::InitMemorySubsystem(JSRuntime *rt)
+ static inline void *
+ MapMemory(size_t length, int prot, int flags, int fd, off_t offset)
+ {
+-#if defined(__ia64__)
++#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && defined(__NetBSD__))
+ /*
+  * The JS engine assumes that all allocated pointers have their high 17 bits clear,
+  * which ia64's mmap doesn't support directly. However, we can emulate it by passing
diff -Nru mozjs24-24.2.0/debian/patches/Use_the_arm64_allocator_on_Linux_sparc64.patch mozjs24-24.2.0/debian/patches/Use_the_arm64_allocator_on_Linux_sparc64.patch
--- mozjs24-24.2.0/debian/patches/Use_the_arm64_allocator_on_Linux_sparc64.patch	1970-01-01 00:00:00.0 +
+++ mozjs24-24.2.0/debian/patches/Use_the_arm64_allocator_on_Linux_sparc64.patch	2017-01-15 18:31:03.0 +
@@ -0,0 +1,21 @@
+
+# HG changeset patch
+# User John Paul Adrian Glaubitz 
+# Date 1482314917 -3600
+# Node ID 0cb0fe7e92f695be45e21c95907bbc6a12664f02
+# Parent  f9307a83e5554072d3bc9167d88562cd5ad131d1
+Bug 1275204 - js: Use the arm64 allocator on Linux/sparc64. r=ehoogeveen
+
+
+diff --git a/js/src/gc/Memory.cpp b/js/src/gc/Memory.cpp
+--- a/js/src/gc/Memory.cpp
 b/js/src/gc/Memory.cpp
+@@ -339,7 +339,7 @@ MapMemory(size_t length, int prot, int f
+ return MAP_FAILED;
+ }
+ return region;
+-#elif defined(__aarch64__)
++#elif defined(__aarch64__) || (defined(__sparc__) && defined(__arch64__) && defined(__linux__))
+/*
+ * There might be similar virtual address issue on arm64 which depends on
+ * hardware and kernel configurations. But the work around is slightly
diff -Nru mozjs24-24.2.0/debian/patches/series mozjs24-24.2.0/debian/patches/series
--- mozjs24-24.2.0/debian/patches/series	2017-01-07 01:42:14.0 +
+++ mozjs24-24.2.0/debian/patches/series	2017-01-15 18:31:03.0 +
@@ -6,3 +6,5 @@
 m68k-support.patch
 Disable-js-JIT-on-x32.patch
 manually-mmap-on-arm64-to-ensure-high-17-bits-are-clear.patch
+Use_better_pre-processor_defines_for_sparc64.patch
+Use_the_arm64_allocator_on_Linux_sparc64.patch

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread James Clarke 
On 15 Jan 2017, at 18:26, Simon McVittie  wrote:
> On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
>> For the time being, Firefox upstream is now using the arm64 workaround on 
>> sparc64
>> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
>> version 53.
> 
> Can you point those interested in this bug to a patch/commit/something that
> describes "the arm64 workaround"? Is it related to #839050?

The upstream commit is 0cb0fe7e92f6[1]. Essentially, it loops over a range of
possible addresses, trying to mmap them until it finds a free one that's big
enough. Ugly, but there's not much alternative until they fix their tagging.
Perhaps we could get this patch included in Debian, if it's not going to be
included in an upstream release soon? I see it was already NMU'ed on arm64 to
fix it there.

Regards,
James

[1] http://hg.mozilla.org/mozilla-central/rev/0cb0fe7e92f6

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread Simon McVittie 
On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
> For the time being, Firefox upstream is now using the arm64 workaround on 
> sparc64
> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
> version 53.

Can you point those interested in this bug to a patch/commit/something that
describes "the arm64 workaround"? Is it related to #839050?

S

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread John Paul Adrian Glaubitz 
On 01/15/2017 04:57 PM, Simon McVittie wrote:
> This is easy to reproduce on the sparc64 porterbox, with or without gjs.
> Possibly related to 
> since standalone mozjs (SpiderMonkey) is essentially a fork of the Firefox
> JavaScript engine.

The problem are tagged pointers which are used by many JavaScript 
implementations
and are basically a crude hack only. They work as long as the underlying 
hardware
does not use any beyond the 48 bit virtual address space which is currently
true for x86_64.

However, the arm64 have already run into this limit as well [1] and I expect 
other
architectures to run into the problem at some point in the future as well. It's
just a bad design to make assumptions about the underlying hardware and violate
the C/C++ specification just to make the Javascript engine faster in some 
benchmarks.

Some needs to fix the Javascript implementations at some point to get rid of 
these
hacks and these issues will all be resolved.

For the time being, Firefox upstream is now using the arm64 workaround on 
sparc64
as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
version 53.

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1143022

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

2017-01-15 Thread Simon McVittie 
Control: retitle 827815 libmozjs-24-0: initialization segfaults on sparc64
Control: user debian-sparc@lists.debian.org
Control: usertags 827815 + sparc64

This is easy to reproduce on the sparc64 porterbox, with or without gjs.
Possibly related to 
since standalone mozjs (SpiderMonkey) is essentially a fork of the Firefox
JavaScript engine.

Sample backtraces below. The expected result of running either js24 or
gjs-console is an interactive prompt at which you can type
print("hello, world!") and get "hello, world!" printed in response.

mozjs24 currently ignores errors during "make check" because not all
tests are reliable, but it would be great if it tried something simpler
like

js24 -e 'print("hello, world!")'

and made the package FTBFS if that didn't work - that would avoid dependent
packages like gjs being built, but actually being unusable, on sparc64.

Regards,
S



With libmozjs-24-bin, libmozjs-24-bin-dbg and libmozjs-24-0-dbg:
> smcv@notker ~ % gdb js24
> ...
> (gdb) run
> Starting program: /usr/bin/js24 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
> [New Thread 0x800101889910 (LWP 250203)]
> [New Thread 0x800102089910 (LWP 250204)]
> 
> Thread 1 "js24" received signal SIGSEGV, Segmentation fault.
> js::ObjectImpl::setFlag (this=this@entry=0x102306040, cx=cx@entry=0x53e610, 
> flag_=flag_@entry=8, 
> generateShape=generateShape@entry=js::ObjectImpl::GENERATE_SHAPE)
> at ./js/src/vm/Shape.cpp:1116
> 1116  ./js/src/vm/Shape.cpp: No such file or directory.
> (gdb) set pagination off
> (gdb) thread apply all bt
> 
> Thread 3 (Thread 0x800102089910 (LWP 250204)):
> #0  0x8001001365a4 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib/sparc64-linux-gnu/libpthread.so.0
> #1  0x80010047e5d8 in PR_WaitCondVar () from 
> /usr/lib/sparc64-linux-gnu/libnspr4.so
> #2  0x002d9150 in js::SourceCompressorThread::threadLoop 
> (this=0x521940) at ./js/src/jsscript.cpp:1094
> #3  js::SourceCompressorThread::compressorThread (arg=0x521940) at 
> ./js/src/jsscript.cpp:965
> #4  0x800100484620 in ?? () from /usr/lib/sparc64-linux-gnu/libnspr4.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 2 (Thread 0x800101889910 (LWP 250203)):
> #0  0x8001001365a4 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib/sparc64-linux-gnu/libpthread.so.0
> #1  0x80010047e5d8 in PR_WaitCondVar () from 
> /usr/lib/sparc64-linux-gnu/libnspr4.so
> #2  0x0025d9a4 in js::GCHelperThread::threadLoop (this=0x521868) at 
> ./js/src/jsgc.cpp:2266
> #3  0x800100484620 in ?? () from /usr/lib/sparc64-linux-gnu/libnspr4.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 1 (Thread 0x800100030f60 (LWP 250200)):
> #0  js::ObjectImpl::setFlag (this=this@entry=0x102306040, 
> cx=cx@entry=0x53e610, flag_=flag_@entry=8, 
> generateShape=generateShape@entry=js::ObjectImpl::GENERATE_SHAPE) at 
> ./js/src/vm/Shape.cpp:1116
> #1  0x00276b94 in JSObject::setDelegate (cx=0x53e610, this= out>) at ./jsobjinlines.h:782
> #2  JSCompartment::getNewType (this=0x53efd0, cx=cx@entry=0x53e610, 
> clasp=clasp@entry=0x4f2e10 , proto_=..., 
> fun_=fun_@entry=0x0) at ./js/src/jsinfer.cpp:6073
> #3  0x00277020 in JSObject::getNewType (this=0x102306040, 
> cx=cx@entry=0x53e610, clasp=clasp@entry=0x4f2e10 , 
> fun=fun@entry=0x0) at ./js/src/jsinfer.cpp:6134
> #4  0x0029f938 in js::NewObjectWithClassProtoCommon (cx=0x53e610, 
> clasp=0x4f2e10 , protoArg=, 
> parentArg=0x800102305020, allocKind=, newKind= out>) at ./js/src/jsobj.cpp:1383
> #5  0x0029fbc4 in js::NewObjectWithClassProtoCommon 
> (cx=cx@entry=0x53e610, clasp=0x7feec60, protoArg=0x7feec70, 
> protoArg@entry=0x0, parentArg=0x170338  int, JS::Value*)>, 
> allocKind=allocKind@entry=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
> newKind=newKind@entry=js::SingletonObject) at ./js/src/jsobj.cpp:1343
> #6  0x002506b8 in js::NewObjectWithClassProto 
> (newKind=js::SingletonObject, allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, 
> parent=, proto=0x0, clasp=0x4f2e10 , 
> cx=0x53e610) at ./jsobjinlines.h:1493
> #7  js::NewFunction (newKind=js::SingletonObject, 
> allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, atom=..., parent=..., 
> flags=, nargs=0, native=0x170338  unsigned int, JS::Value*)>, funobjArg=..., cx=0x53e610) at 
> ./js/src/jsfun.cpp:1561
> #8  js::DefineFunction (cx=cx@entry=0x53e610, obj=..., id=..., 
> native=0x170338 , 
> nargs=, flags=0, flags@entry=512, 
> allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, newKind=js::GenericObject) at 
> ./js/src/jsfun.cpp:1688
> #9  0x001fc2a4 in JS_DefineFunctions (cx=cx@entry=0x53e610, 
> objArg=, fs=0x4e6aa8 )