On Thu, Jan 24, 2019 at 04:42:28PM -0000, BLFS Trac wrote:
> #11521: Upgrade rustc for firefox-65.0
> -------------------------+-----------------------
> Reporter: ken@… | Owner: ken@…
> Type: enhancement | Status: assigned
> Priority: normal | Milestone: 8.4
> Component: BOOK | Version: SVN
> Severity: normal | Resolution:
> Keywords: |
> -------------------------+-----------------------
>
> Comment (by renodr):
>
(replying to the list, I'm not at my desktop and don't have trac
identity set on this old netbook)
> > > Getting a traceback is normal (one or more tests failed). 4 failures
> is probably ok.
> > > If you look for FAIL in the log, I will guess that the last one is
> sysroot-crates-are-unstable in run-make ?
> > >
Is it ?
> > > >
> > > > This is a big improvement over *system* LLVM though:
> > > >
> > >
> > > I assume you discarded that log. If not, or in your systemd journal, I
> assume there are many segfaults (two, and a number of traps for invalid
> opcodes, are normal).
> >
> > My totals (with only 3 failed tests are 15687 passed, 108 ignored (if
> gdb is present), or 15605 and 190 if gdb is not available. The totals are
> about 3 greater than the claimed number of tests.
> >
> With GDB installed, I get 15795 total tests, 4 "failures", and 108
> ignored.
>
> > For miri I am now using
> > {{{
> > export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" &&
> > ./x.py build --exclude src/tools/miri
> > }}}
> >
> > You added your traces and segfaults while I was writing that, can you
> look at the latest log and search for segfault / sigsegv / signal 11 to
> find out if any were reported in the output.
> >
>
> It doesn't seem that any are reported, at least via a simple grep. I can
> upload my rustc-testlog to my webspace if that'll help at all.
>
I don't have time to look at the moment - going out shortly. But
what I do is (from memory, maybe flakey) look for FAIL in the test
log, then work back. In recent versions I think any failed tests
are reported by each batch with a neat 'failed:' header giving their
names. The three in the ui/ area are because we don't build for
ARM.
> As an example of one of my coredumps (seems to be a SIGABRT):
>
> {{{
> PID: 17753 (a)
> UID: 1000 (renodr)
> GID: 1000 (renodr)
> Signal: 6 (ABRT)
> Timestamp: Wed 2019-01-23 23:23:14 CST (11h ago)
> Command Line: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-
> gnu/test/run-pass/stack-probes-lto/a child-thread
> Executable: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-
> gnu/test/run-pass/stack-probes-lto/a
> Control Group: /system.slice/sshd.service
> Unit: sshd.service
> Slice: system.slice
> Boot ID: b14abce378314253b307b60837c5de6f
> Machine ID: 7777b247b5d14d1d980532e847b5461b
> Hostname: POOH
> Storage:
>
> /var/lib/systemd/coredump/core.a.1000.b14abce378314253b307b60837c5de6f.17753.1548307394000000.xz
> Message: Process 17753 (a) of user 1000 dumped core.
>
> }}}
>
No idea.
ĸen
--
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
