tcam...@mozilla.com schrieb am Freitag, 12. März 2021 um 20:14:54 UTC+1:
> On Friday, March 12, 2021 at 6:20:41 AM UTC-5, grze...@gmail.com wrote:
> > tcam...@mozilla.com schrieb am Freitag, 12. März 2021 um 02:12:11 UTC+1:
> > > On Thursday, March 11, 2021 at 1:15:42 PM UTC-5, grze...@gmail.com wrote:
> > > > Carsten Grzemba schrieb am Donnerstag, 11. März 2021 um 14:25:41 UTC+1:
> > > > > Lars Hansen schrieb am Donnerstag, 11. März 2021 um 13:25:45 UTC+1:
> > > > > > If you run jit-tests with the options -f --no-xdr it will print out
> > > > > > the
> > > > > > command lines you need to use to run the failed tests individually.
> > > > > >
> > > > > > --lrs
> > > > > > On Thu, Mar 11, 2021 at 12:05 PM Carsten Grzemba
> > > > > > <grze...@gmail.com> wrote:
> > > > > >
> > > > > > > I attempt to build Firefox for Openindiana (Illumos). Some of the
> > > > > > > tests
> > > > > > > are failing:
> > > > > > > Result summary:
> > > > > > > Passed: 30561
> > > > > > > Failed: 480
> > > > > > >
> > > > > > > How can I check what the reason for a failed check is?
> > > > > > >
> > > > > > > In the log I see for example:
> > > > > > > TEST-PASS |
> > > > > > > js/src/jit-test/tests/wasm/timeout/debug-interrupt-2.js |
> > > > > > > Success (code 6, args "--ion-eager --ion-offthread-compile=off
> > > > > > > --more-compartments") [1.0 s]
> > > > > > > #1 module successfully instantiated: PASS.
> > > > > > > #2 A wast module that must return a particular value.: PASS.
> > > > > > > #3 A wast module that must trap at runtime.: PASS.
> > > > > > > #4 A wast module that must trap at runtime.: PASS.
> > > > > > > #5 A wast module that must trap at runtime.: PASS.
> > > > > > > #6 A wast module that must trap at runtime.: PASS.
> > > > > > > Exit code: -11
> > > > > > > FAIL - wasm/spec/memory_grow.wast.js
> > > > > > > TEST-UNEXPECTED-FAIL |
> > > > > > > js/src/jit-test/tests/wasm/spec/memory_grow.wast.js
> > > > > > > | Unknown (code -11, args "--ion-eager
> > > > > > > --ion-offthread-compile=off
> > > > > > > --ion-check-range-analysis --ion-extra-checks --no-sse3
> > > > > > > --no-threads")
> > > > > > > [20.0 s]
> > > > > > > INFO exit-status : -11
> > > > > > > INFO timed-out : False
> > > > > > > INFO stdout > #1 module successfully instantiated: PASS.
> > > > > > > INFO stdout > #2 A wast module that must return a particular
> > > > > > > value.: PASS.
> > > > > > > INFO stdout > #3 A wast module that must trap at runtime.: PASS.
> > > > > > > INFO stdout > #4 A wast module that must trap at runtime.: PASS.
> > > > > > > INFO stdout > #5 A wast module that must trap at runtime.: PASS.
> > > > > > > INFO stdout > #6 A wast module that must trap at runtime.: PASS.
> > > > > > >
> > > > > > > TEST-PASS | js/src/jit-test/tests/wasm/timeout/1.js | Success
> > > > > > > (code 6,
> > > > > > > args "--wasm-compiler=baseline") [1.2 s]
> > > > > > >
> > > > > > > How can I run a test standalone, perhapse with a little bit more
> > > > > > > informations?
> > > > > > > _______________________________________________
> > > > > > > dev-platform mailing list
> > > > > > > dev-pl...@lists.mozilla.org
> > > > > > > https://lists.mozilla.org/listinfo/dev-platform
> > > > > > >
> > > > > cool!
> > > > > thats is what Im looking for:
> > > > >
> > > > > grzemba@oibuild:~/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test$
> > > > >
> > > > > /ws/grzemba/oi-userland/components/web/firefox/build_opt/amd64/dist/bin/js
> > > > > -f
> > > > > /ws/grzemba/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test/lib/prologue.js
> > > > > -e 'const platform='"'"'sunos5'"'"'' -e 'const
> > > > > libdir='"'"'/ws/grzemba/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test/lib/'"'"''
> > > > > -e 'const
> > > > > scriptdir='"'"'/ws/grzemba/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test/tests/asm.js/'"'"''
> > > > > -e 'if ((!this.SharedArrayBuffer || !isAsmJSCompilationAvailable()))
> > > > > quit(59)' --module-load-path
> > > > > /ws/grzemba/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test/modules/
> > > > > -f
> > > > > /ws/grzemba/oi-userland/components/web/firefox/firefox-68.12.0/js/src/jit-test/tests/asm.js/testBug1057248.js
> > > > >
> > > > > Segmentation Fault (core dumped)
> > > > >
> > > > > core 'core' of 4573:
> > > > > /ws/grzemba/oi-userland/components/web/firefox/build_opt/amd64/dist/bin
> > > > >
> > > > > --------------------- thread# 1 / lwp# 1 ---------------------
> > > > > 0000000000d51211
> > > > > js::InternalBarrierMethods<JS::Value>::preBarrier(JS::Value const&)
> > > > > () + 5b3
> > > > > 0000000000b43671 js::SharedArrayBufferObject::dropRawBuffer() () + 33
> > > > > 0000000000b436eb js::SharedArrayBufferObject::Finalize(js::FreeOp*,
> > > > > JSObject*) () + 51
> > > > > 0000000000d3b700 bool FinalizeTypedArenas<JSObject>(js::FreeOp*,
> > > > > js::gc::Arena**, js::gc::SortedArenaList&, js::gc::AllocKind,
> > > > > js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) () + 211
> > > > > 0000000000d3bb98 FinalizeArenas(js::FreeOp*, js::gc::Arena**,
> > > > > js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&,
> > > > > js::gc::ArenaLists::KeepArenasEnum) () + 187
> > > > > 0000000000d3f124 js::gc::ArenaLists::backgroundFinalize(js::FreeOp*,
> > > > > js::gc::Arena*, js::gc::Arena**) () + b0
> > > > > 0000000000d3f39a
> > > > > js::gc::GCRuntime::sweepBackgroundThings(js::gc::ZoneList&,
> > > > > js::LifoAlloc&) () + ba
> > > > > 0000000000d3f6b2
> > > > > js::gc::GCRuntime::sweepFromBackgroundThread(js::AutoLockHelperThreadState&)
> > > > > () + 124
> > > > > 0000000000d3fa13 js::gc::BackgroundSweepTask::run() () + 47
> > > > > 0000000000d3fa50
> > > > > js::GCParallelTaskHelper<js::gc::BackgroundSweepTask>::runTaskTyped(js::GCParallelTask*)
> > > > > () + 9
> > > > > 00000000009f0ebf js::GCParallelTask::runTask() () + 7
> > > > > 00000000009f3f90 js::GCParallelTask::runFromMainThread(JSRuntime*) ()
> > > > > + 20
> > > > > 00000000009f403b
> > > > > js::GCParallelTask::joinAndRunFromMainThread(JSRuntime*) () + 5b
> > > > > 0000000000d2da40
> > > > > js::gc::GCRuntime::queueZonesAndStartBackgroundSweep(js::gc::ZoneList&)
> > > > > () + 9c
> > > > > 0000000000d2de3a
> > > > > js::gc::GCRuntime::endSweepingSweepGroup(js::FreeOp*,
> > > > > js::SliceBudget&) () + 1e4
> > > > > 0000000000d275c0 sweepaction::SweepActionCall<js::FreeOp*,
> > > > > js::SliceBudget&>::run(js::gc::GCRuntime*, js::FreeOp*,
> > > > > js::SliceBudget&) () + 2c
> > > > > 0000000000d28fdf sweepaction::SweepActionSequence<js::gc::GCRuntime*,
> > > > > js::FreeOp*, js::SliceBudget&>::run(js::gc::GCRuntime*, js::FreeOp*,
> > > > > js::SliceBudget&) () + 39
> > > > > 0000000000d2e940
> > > > > sweepaction::SweepActionRepeatFor<js::gc::SweepGroupsIter,
> > > > > JSRuntime*, js::gc::GCRuntime*, js::FreeOp*,
> > > > > js::SliceBudget&>::run(js::gc::GCRuntime*, js::FreeOp*,
> > > > > js::SliceBudget&) () + 3e
> > > > > 0000000000d5ea4f
> > > > > js::gc::GCRuntime::performSweepActions(js::SliceBudget&) () + 67
> > > > > 0000000000d5ee53
> > > > > js::gc::GCRuntime::incrementalSlice(js::SliceBudget&, JS::GCReason,
> > > > > js::gc::AutoGCSession&) () + 3ad
> > > > > 0000000000d5f37e js::gc::GCRuntime::gcCycle(bool, js::SliceBudget,
> > > > > JS::GCReason) () + 1fc
> > > > > 0000000000d5f83c js::gc::GCRuntime::collect(bool, js::SliceBudget,
> > > > > JS::GCReason) () + b2
> > > > > 0000000000d5fa6d js::gc::GCRuntime::gc(JSGCInvocationKind,
> > > > > JS::GCReason) () + 4f
> > > > > 0000000000aaa4cd JSRuntime::destroyRuntime() () + 13d
> > > > > 0000000000a1be11 js::DestroyContext(JSContext*) () + a9
> > > > > 0000000000c14e5f JS_DestroyContext(JSContext*) () + 9
> > > > > 00000000008560e6 main () + 21fb
> > > > > 0000000000836427 _start_crt () + 87
> > > > > 0000000000836388 _start () + 18
> > > > For the failed tests I get core dumps initiated by
> > > > MOZ_ASSERT(isDouble()) in setPrivate(void*) mostly, with stack traces
> > > > similar like this:
> > > > --------------------- thread# 1 / lwp# 1 ---------------------
> > > > 0000000001c85879 JS::Value::setPrivate(void*) () + af
> > > > 0000000001edda15 JS::PrivateValue(void*) () + 3d
> > > > 0000000001ee9320
> > > > js::ArrayBufferObject::setDataPointer(js::ArrayBufferObject::BufferContents)
> > > > () + 32
> > > >
> > > > I assume the core is the wanted behaviour of the MOZ_ASSERT.
> > > > How can I investigate was is going wrong here?
> > > > I do the test with Firefox 68.1.20 esr. What I can found on
> > > > https://bugzilla.mozilla.org is related to newer versions of FF and the
> > > > failed test for bugs very old.
> > > >
> > > > Many Thanks
> > > This sounds like you are hitting Bug 1568564 where the encoding of
> > > `PrivateValue` type acted up on certain compiler configurations in
> > > Firefox 68 ESR. We did backport a workaround to Firefox 68.2.0+ that
> > > added an optional --enable-unaligned-private-values compilation flag. If
> > > this flag is available in your version you should give it a try.
> > >
> > > The issue in that bug is that the code expects a certain alignment that
> > > was stricter than some compiler / OS pairs guaranteed.
> > The comment in setPrivate mentions: ptr must be a valid user-mode pointer,
> > with the top 16 bits clear.
> > But if I get the assertion, than the ptr is 0xfffffbffef120fb0
> > Where do the pointer come from? In the sense of pointer the address is ok,
> > it should be an mmap'ed area, but why expects setPrivate whith the top 16
> > bits clear?
> The JS::Value representation uses a technique called "NaN-boxing" to encoding
> pointers as special versions of floating-point NaN values. In this approach,
> there is a limited number of bits available for storing pointer values. To
> work around this we take advantage of the fact that 64-bit processors
> generally do not use 64-bits of actual address space yet. See this wikipedia
> diagram for more info:
> https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details . In that
> diagram there is an "upper" and "lower" half of memory. While it is possible
> to sign-extend the 48-bit number to 64-bit to get the expected value, we find
> that the main operating systems we support don't use the "upper" region for
> user-space pointers so we avoid performance overhead of this 48->64
> sign-extension.
>
> If this failure mostly experienced in these WASM SharedArrayBuffer cases, you
> may be able to modify where the mmap is called. I don't know what the
> appropriate way on your OS to get a page that is in the "lower" half of
> memory.
> https://searchfox.org/mozilla-central/rev/491c8096b5dfdb328b2135895062e16e1e36d708/mfbt/TaggedAnonymousMemory.cpp#85
>
>
> If you are investigating possible mmap solutions, it may be helpful to look
> at the "scattershot" allocation that the GC uses:
> https://searchfox.org/mozilla-central/rev/491c8096b5dfdb328b2135895062e16e1e36d708/js/src/gc/Memory.cpp#467-487
I compiled without the option --enable-jemalloc.
Can I expect a different behavior here if I compile with --enable-jemalloc ? Or
it this mmap usage beside jemalloc.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
