Closed Bug 1413887 Opened 8 years ago Closed 8 years ago

run custom build command for style v0.0.1 cores dump on Solaris sparc

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: petr.sumbera, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20171024165158 Steps to reproduce: While trying to build trunk on sparc Solaris (intel seems to be just fine) I get : gmake[1]: Entering directory '/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/rust' force-cargo-library-build env RUSTFLAGS='-C opt-level=1 -C debuginfo=2 ' CARGO_TARGET_DIR=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library RUSTC=/usr/bin/rustc MOZ_SRC=/scratch/firefox MOZ_DIST=/scratch/firefox/obj-sparc64-sun-solaris2.11/dist LIBCLANG_PATH="/usr/lib/sparcv9" CLANG_PATH="/usr/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/scratch/firefox/obj-sparc64-sun-solaris2.11 MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,-z,text -L/scratch/firefox/obj-sparc64-sun-solaris2.11/dist/bin" MOZ_CARGO_WRAP_LD=" /usr/bin/gcc -std=gnu99" CARGO_TARGET_SPARCV9_SUN_SOLARIS_LINKER=/scratch/firefox/build/cargo-linker /usr/bin/cargo rustc --release --frozen --manifest-path /scratch/firefox/toolkit/library/rust/Cargo.toml --lib --target=sparcv9-sun-solaris --features "servo bindgen quantum_render cubeb_pulse_rust no-static-ideograph-encoder-tables" -- Compiling style v0.0.1 (file:///scratch/firefox/servo/components/style) error: failed to run custom build command for `style v0.0.1 (file:///scratch/firefox/servo/components/style)` process didn't exit successfully: `/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/build/style-77dab90d61f1eee5/build-script-build` (signal: 11, SIGSEGV: invalid memory reference) --- stdout cargo:rerun-if-changed=build.rs .. cargo:rerun-if-changed=/scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/nsCSSAnonBoxList.h /scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/sparcv9-sun-solaris/release/build/style-9c1f3ff29327b976/out/gecko/atom_macro.rs is not changed, skip cargo:rerun-if-changed=/scratch/firefox/servo/components/style/gecko/pseudo_element_definition.mako.rs /scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/sparcv9-sun-solaris/release/build/style-9c1f3ff29327b976/out/gecko/pseudo_element_definition.rs is not changed, skip --- stderr /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:202:1: warning: replacement function 'operator new' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:209:21: warning: replacement function 'operator new' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:215:21: warning: replacement function 'operator new[]' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:221:21: warning: replacement function 'operator new[]' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:227:21: warning: replacement function 'operator delete' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:241:21: warning: replacement function 'operator delete' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:247:21: warning: replacement function 'operator delete[]' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/mozilla/mozalloc.h:261:21: warning: replacement function 'operator delete[]' cannot be declared 'inline' [-Winline-new-delete], err: false /scratch/firefox/obj-sparc64-sun-solaris2.11/dist/include/js/Proxy.h:212:16: warning: offset of on non-standard-layout type 'js::BaseProxyHandler' [-Winvalid-offsetof], err: false gmake[1]: *** [/scratch/firefox/config/rules.mk:976: force-cargo-library-build] Error 101 gmake[1]: Leaving directory '/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/rust' Core file looks like this: t@3 (l@3) terminated by signal SEGV (no mapping at the fault address) 0xffffffff795fe5dc: clang_getTranslationUnitCursor+0x004c: ldx [%g1 + 1928], %o0 (dbx) where current thread: t@3 =>[1] clang_getTranslationUnitCursor(0xffffffff7e9d98f8, 0xffffffff75820660, 0x8, 0x0, 0x3, 0xffffffff7c604438), at 0xffffffff795fe5dc [2] clang_sys::clang_getTranslationUnitCursor::ha150bdb5cbcc6e65(0xffffffff7e9d98f8, 0xffffffff75820660, 0xffffffff795fe590, 0xffffffff7da13eb0, 0x0, 0x0), at 0x1003e3344 [3] bindgen::Builder::generate::h16740e61515c1b74(0x0, 0xffffffff7e9da208, 0x0, 0xffffffff7d20e3c8, 0xffffffff7e9d9118, 0x10067f6b0), at 0x1002b77f0 [4] build_script_build::build_gecko::bindings::write_binding_file::hc72b77a111fba79e(0xffffffff7e9dbc10, 0xffffffff7e9dc0a8, 0xb, 0xffffffff7da2a000, 0x2, 0x7f), at 0x100192d1c [5] build_script_build::build_gecko::bindings::generate_bindings::h02c7bb9989eec886(0xffffffff7e9dd5c8, 0x330, 0x0, 0xffffffff7e9dcbd8, 0xffffffff7e9ded58, 0x0), at 0x10019fc34 [6] std::sys_common::backtrace::__rust_begin_short_backtrace::h5bba3a660249a2e8(0xffffffff7da0c000, 0xffffffff7da0c000, 0xffffffff7e9dfc18, 0xffffffff7f560aa0, 0x20, 0x0), at 0x10017f854 [7] std::panicking::try::do_call::hde93a1e13b925f03(0xffffffff7e9dfe38, 0x8590, 0x10067ab68, 0x0, 0x0, 0x0), at 0x100182e50 [8] __rust_maybe_catch_panic(0x100182e4c, 0xffffffff7e9dfe38, 0xffffffff7e9dfe30, 0xffffffff7e9dfe20, 0x100640b38, 0x0), at 0x1004d76cc [9] _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::haaacef44ad29090c(0x100640b38, 0x48, 0xffffffff7ec1c060, 0xffffffff7e9dfe10, 0xffffffffffffffff, 0x0), at 0x100188b74 [10] std::sys::imp::thread::Thread::new::thread_start::h40999f9bd27b95bc(0x100188ae8, 0xffffffff7f5cc000, 0xffffffff7ec1c070, 0x100640b38, 0x0, 0x0), at 0x1004cc274 It fails in this function: (dbx) dis clang_getTranslationUnitCursor /21 0xffffffff795fe590: clang_getTranslationUnitCursor : save %sp, -272, %sp 0xffffffff795fe594: clang_getTranslationUnitCursor+0x0004: sethi %hi(0x0), %i5 0xffffffff795fe598: clang_getTranslationUnitCursor+0x0008: sethi %hi(0x15cd800), %l7 0xffffffff795fe59c: clang_getTranslationUnitCursor+0x000c: inc 608, %l7 0xffffffff795fe5a0: clang_getTranslationUnitCursor+0x0010: call l7 ! 0xffffffff795e3aec 0xffffffff795fe5a4: clang_getTranslationUnitCursor+0x0014: nop 0xffffffff795fe5a8: clang_getTranslationUnitCursor+0x0018: btog 64, %i5 0xffffffff795fe5ac: clang_getTranslationUnitCursor+0x001c: ldx [%l7 + %i5], %i5 0xffffffff795fe5b0: clang_getTranslationUnitCursor+0x0020: ldx [%i5], %g1 0xffffffff795fe5b4: clang_getTranslationUnitCursor+0x0024: stx %g1, [%fp + 2039] 0xffffffff795fe5b8: clang_getTranslationUnitCursor+0x0028: clr %g1 0xffffffff795fe5bc: clang_getTranslationUnitCursor+0x002c: brz,pn %i0, clang_getTranslationUnitCursor+0x9c ! 0xffffffff795fe62c 0xffffffff795fe5c0: clang_getTranslationUnitCursor+0x0030: nop 0xffffffff795fe5c4: clang_getTranslationUnitCursor+0x0034: ldx [%i0 + 8], %g1 0xffffffff795fe5c8: clang_getTranslationUnitCursor+0x0038: mov 1, %o3 0xffffffff795fe5cc: clang_getTranslationUnitCursor+0x003c: mov %i0, %o1 0xffffffff795fe5d0: clang_getTranslationUnitCursor+0x0040: clr [%fp + 1991] 0xffffffff795fe5d4: clang_getTranslationUnitCursor+0x0044: ldx [%g1 + 80], %g1 0xffffffff795fe5d8: clang_getTranslationUnitCursor+0x0048: clr [%fp + 1995] 0xffffffff795fe5dc: clang_getTranslationUnitCursor+0x004c: ldx [%g1 + 1928], %o0 0xffffffff795fe5e0: clang_getTranslationUnitCursor+0x0050: ldx [%fp + 1991], %o2 Though not sure now whether this is Firefox (trunk), Rust (1.21), Bindgen or Clang (5.0.0) issue. Any advice is much appreciated.
Component: Untriaged → Build Config
Product: Firefox → Core
Following is more detailed output (with --verbose and just with "bindgen") env RUSTFLAGS='-C opt-level=1 -C debuginfo=2 ' CARGO_TARGET_DIR=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library RUSTC=/usr/bin/rustc MOZ_SRC=/scratch/firefox MOZ_DIST=/scratch/firefox/obj-sparc64-sun-solaris2.11/dist LIBCLANG_PATH="/usr/lib/sparcv9" CLANG_PATH="/usr/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/scratch/firefox/obj-sparc64-sun-solaris2.11 MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,-z,text -L/scratch/firefox/obj-sparc64-sun-solaris2.11/dist/bin" MOZ_CARGO_WRAP_LD=" /usr/bin/gcc -std=gnu99" CARGO_TARGET_SPARCV9_SUN_SOLARIS_LINKER=/scratch/firefox/build/cargo-linker /usr/bin/cargo rustc --verbose --release --frozen --manifest-path /scratch/firefox/toolkit/library/rust/Cargo.toml --lib --target=sparcv9-sun-solaris --features "bindgen" -- Fresh either v1.1.0 .. Compiling style v0.0.1 (file:///scratch/firefox/servo/components/style) Fresh selectors v0.19.0 (file:///scratch/firefox/servo/components/selectors) Fresh style_traits v0.0.1 (file:///scratch/firefox/servo/components/style_traits) Running `/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/build/style-77dab90d61f1eee5/build-script-build` error: failed to run custom build command for `style v0.0.1 (file:///scratch/firefox/servo/components/style)` process didn't exit successfully: `/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/build/style-77dab90d61f1eee5/build-script-build` (signal: 11, SIGSEGV: invalid memory reference) Anyone has an idea how to run directly the binary? I tried following but it doesn't seem to be right way (it doesn't core dump and the error is different): $ CARGO_TARGET_SPARCV9_SUN_SOLARIS_LINKER=/scratch/firefox/build/cargo-linker MOZ_CARGO_WRAP_LD="/usr/bin/gcc -std=gnu99" MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,-z,text -L/scratch/firefox/obj-sparc64-sun-solaris2.11/dist/bin" MOZ_TOPOBJDIR=/scratch/firefox/obj-sparc64-sun-solaris2.11 RUST_BACKTRACE=full PKG_CONFIG_ALLOW_CROSS=1 CLANG_PATH=/usr/bin/clang LIBCLANG_PATH=/usr/lib/sparcv9 MOZ_DIST=/scratch/firefox/obj-sparc64-sun-solaris2.11/dist MOZ_SRC=/scratch/firefox RUSTC=/usr/bin/rustc CARGO_TARGET_DIR=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library RUSTFLAGS="-C opt-level=1 -C debuginfo=2" OLDPWD=/scratch/firefox/obj-sparc64-sun-solaris2.11 CARGO_CFG_TARGET_FAMILY=unix NUM_JOBS=4 DEBUG=false CARGO_FEATURE_STYLE_TRAITS=1 CARGO_FEATURE_BINDGEN=1 CARGO_PKG_VERSION_MAJOR=0 HOST=sparcv9-sun-solaris CARGO_MANIFEST_DIR=/scratch/firefox/servo/components/style CARGO=/usr/bin/cargo CARGO_FEATURE_USE_BINDGEN=1 CARGO_CFG_PROC_MACRO= CARGO_CFG_TARGET_ENDIAN=big OPT_LEVEL=2 CARGO_FEATURE_FALLIBLE=1 PROFILE=release LD_LIBRARY_PATH=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/deps:/usr/lib CARGO_FEATURE_NUM_CPUS=1 RUSTDOC=rustdoc CARGO_FEATURE_REGEX=1 CARGO_FEATURE_TOML=1 CARGO_CFG_TARGET_POINTER_WIDTH=64 CARGO_PKG_VERSION_MINOR=0 CARGO_FEATURE_GECKO=1 CARGO_MANIFEST_LINKS="for some reason the links key is required to pass data around between build scripts" CARGO_CFG_TARGET_ENV= CARGO_PKG_HOMEPAGE= CARGO_CFG_TARGET_ARCH=sparc64 TARGET=sparcv9-sun-solaris CARGO_PKG_DESCRIPTION= CARGO_CFG_UNIX=18129: CARGO_CFG_TARGET_OS=solaris CARGO_PKG_VERSION=0.0.1 CARGO_PKG_NAME=style CARGO_PKG_AUTHORS="The Servo Project Developers" OUT_DIR=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/sparcv9-sun-solaris/release/build/style-9c1f3ff29327b976/out CARGO_PKG_VERSION_PATCH=1 CARGO_FEATURE_NSSTRING=1 CARGO_PKG_VERSION_PRE= CARGO_MAKEFLAGS="--jobserver-fds=5,6 -j --jobserver-auth=5,6 -j" /scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/build/style-77dab90d61f1eee5/build-script-build cargo:rerun-if-changed=build.rs cargo:out_dir=/scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/sparcv9-sun-solaris/release/build/style-9c1f3ff29327b976/out thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { depth: 0, inner: Io { path: Some("properties"), err: Error { repr: Os { code: 2, message: "No such file or directory" } } } }', /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libcore/result.rs:906:4 stack backtrace: 0: 0x1004bd5e3 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hdeea0b1f67186074 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: 0x1004b6d13 - std::sys_common::backtrace::_print::hdee07d373d4b1f34 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/sys_common/backtrace.rs:71 2: 0x1004cd6f3 - std::panicking::default_hook::{{closure}}::hb15f9817f7021eb7 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/sys_common/backtrace.rs:60 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:381 3: 0x1004cd397 - std::panicking::default_hook::hf12ac2c947080b78 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:397 4: 0x1004cdedf - std::panicking::rust_panic_with_hook::h6349f9b5c320bc0e at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:611 5: 0x1004cdcdf - std::panicking::begin_panic::hd4f5b52fc37d29a7 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:572 6: 0x1004cdba7 - std::panicking::begin_panic_fmt::h89452cb9fcdc3eef at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:522 7: 0x1004cdb0f - rust_begin_unwind at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:498 8: 0x10052403f - core::panicking::panic_fmt::h3e574840699b8d64 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libcore/panicking.rs:71 9: 0x100188a17 - core::result::unwrap_failed::he48b25a0442cd9fe 10: 0x1001a388f - build_script_build::main::h1f9f916d04d11072 11: 0x1004b98c7 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd6334804a2dbe4d9 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libcore/ops/function.rs:223 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/sys_common/backtrace.rs:136 12: 0x1004cd9d3 - std::panicking::try::do_call::hd1cfde8c5dbdc033 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/rt.rs:62 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:480 13: 0x1004d76d3 - __rust_maybe_catch_panic at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libpanic_unwind/lib.rs:99 14: 0x1004cf09f - std::rt::lang_start::hf962a6d003ab04a6 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panicking.rs:459 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/panic.rs:361 at /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libstd/rt.rs:61 15: 0x1001a4403 - main 16: 0x10017e90b - <unknown>
Presumably trying to run with CARGO_MAKEFLAGS in an environment where you're not executing the binary from inside `make` will not end very well. Try removing that environment variable?
CARGO_MAKEFLAGS isn't enough. There is no difference in output. I should probably say that without setting anything in environment I get: /scratch/firefox/obj-sparc64-sun-solaris2.11/toolkit/library/release/build/style-77dab90d61f1eee5/build-script-build cargo:rerun-if-changed=build.rs thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotPresent', /scratch/userland-rust-s11.3/components/rust/rustc/rustc-1.21.0-src/src/libcore/result.rs:906:4 note: Run with `RUST_BACKTRACE=1` for a backtrace.
I don't really need to run style-77dab90d61f1eee5/build-script-build manually. I seem to be able to attach to it with debugger before it crashes. CXXUnit->getASTContext() seems to return pointer to unmapped memory and thus .getTranslationUnitDecl() SIGSEGVs... Maybe I should have look at it from Bindgen side (it's being called from rust/bindgen/src/clang.rs: pub fn cursor(&self)).
Maybe FFI is broken similar to bug 1401093 comment 34. Does bindgen work fine on Solaris/x86-64?
Jan, in my case (64bit sparc) your example doesn't crash. Also I can still build Firefox on x86-64 and it also runs (though not very stable at this moment).
Martin, John, have you tried to build Firefox 57 or later on NetBSD/sparc64 or Linux/sparc64? I think, the issue here may not be Solaris-specific.
Flags: needinfo?(martin)
Flags: needinfo?(glaubitz)
There are still some unresolved issues with Rust on sparc64. There are patches available though, but they are not merged yet as we haven't agreed on the particular solution yet. In particular these are: > https://github.com/rust-lang/rust/issues/45509 > https://github.com/rust-lang/llvm/pull/94 For Solaris, please also make sure you have this fix: > https://github.com/rust-lang/rust/pull/45508 I haven't looked into building Rust-based Firefox on sparc64 yet due to the aforementioned issues. Once the issues have been resolved, I will look into Firefox itself.
Flags: needinfo?(glaubitz)
No easy testing for me, rust linking is broken (https://github.com/rust-lang/rust/issues/45686)
Flags: needinfo?(martin)
I seem to be able to reproduce the issue outside of Firefox: mkdir src cat > Cargo.toml <<EOF [package] name = "test" version = "0.1.0" [dependencies] bindgen = "0.31.3" EOF cat > src/main.rs <<EOF extern crate bindgen; use std::env; use std::path::PathBuf; fn main() { println!("cargo:rustc-link-lib=bz2"); let bindings = bindgen::Builder::default() .header("wrapper.h") .generate() .expect("Unable to generate bindings"); let out_path = PathBuf::from(env::var("OUT_DIR").unwrap()); bindings .write_to_file(out_path.join("bindings.rs")) .expect("Couldn't write bindings!"); } EOF cat > wrapper.h <<EOF #include <bzlib.h> EOF --- $ cargo build Updating registry `https://github.com/rust-lang/crates.io-index` Compiling libloading v0.4.2 Compiling libc v0.2.33 Compiling peeking_take_while v0.1.2 Compiling log v0.3.8 Compiling utf8-ranges v1.0.0 Compiling unicode-width v0.1.4 Compiling regex-syntax v0.4.1 Compiling lazy_static v0.2.11 Compiling cfg-if v0.1.2 Compiling strsim v0.6.0 Compiling bindgen v0.31.3 Compiling ansi_term v0.9.0 Compiling vec_map v0.8.0 Compiling glob v0.2.11 Compiling bitflags v0.9.1 Compiling quote v0.3.15 Compiling void v1.0.2 Compiling memchr v1.0.2 Compiling atty v0.2.3 Compiling which v1.0.3 Compiling textwrap v0.9.0 Compiling unreachable v1.0.0 Compiling nom v3.2.1 Compiling aho-corasick v0.6.3 Compiling clang-sys v0.21.0 Compiling thread_local v0.3.4 Compiling clap v2.27.1 Compiling regex v0.2.2 Compiling cexpr v0.2.2 Compiling env_logger v0.4.3 Compiling test v0.1.0 (file:///scratch) Finished dev [unoptimized + debuginfo] target(s) in 221.42 secs $ LIBCLANG_PATH=/usr/lib/sparcv9 ./target/debug/test cargo:rustc-link-lib=bz2 Segmentation Fault (core dumped) $ dbx ./target/debug/test core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 8.2' in your .dbxrc Reading test core file header read successfully Reading ld.so.1 Reading libresolv.so.2 Reading libgcc_s.so.1 Reading libc.so.1 Reading libm.so.2 Reading libclang.so.5.0 Reading libdl.so.1 Reading libLLVM-5.0.so Reading libstdc++.so.6.0.21 Reading librt.so.1 Reading libssp.so.0.0.0 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libffi.so.6.0.4 Reading libedit.so.0.0.53 Reading libcurses.so.1 Reading libz.so.1 t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address) 0xffffffff6b3febdc: clang_getTranslationUnitCursor+0x012c: ldx [%g1 + 1928], %o0 (dbx) where current thread: t@1 =>[1] clang_getTranslationUnitCursor(0xffffffff7fff8fd0, 0xffffffff6cbb3b08, 0xffffffff6b30c178, 0xffffffff6cbb3af8, 0xffffffff7c22e1e8, 0xffffffff7c604438), at 0xffffffff6b3febdc [2] clang_sys::clang_getTranslationUnitCursor::hd637179d0877ee0b(0xffffffff6b3feab0, 0x10100d450, 0x10100d450, 0xffffffff7dc20390, 0x8, 0xffffffff7fff8f38), at 0x100a46274 [3] bindgen::clang::TranslationUnit::cursor::h399194c00a3b6b2c(0xffffffff7fff9238, 0xffffffff7fffa510, 0xffffffff7fffa510, 0xffffffff7fff9140, 0x8, 0xffffffff7fff9150), at 0x10071e2e4 [4] bindgen::parse::h2266b30545569151(0x0, 0x10100d450, 0xffffffff7fffa3d0, 0xffffffff7fffb040, 0xffffffff7fffb018, 0x0), at 0x10081cd68 [5] bindgen::Bindings::generate::habfe56eb37301abd(0x3438, 0x10100d450, 0x10100d450, 0xffffffff7fffd740, 0xffffffff7fff94e0, 0x468), at 0x1008188d4 [6] bindgen::Builder::generate::hf13d593428992670(0xffffffff7fffe140, 0xffffffff7fffd450, 0xffffffff7fffe5c0, 0xffffffff7fffccd8, 0x498, 0x1004d2710), at 0x100814638 [7] test::main::h1f7acdf9b8bc2bae(0x58, 0x10100d450, 0xffffffff7ec0c040, 0xffffffff7f5c2a80, 0xffffffff7c22f3c0, 0x0), at 0x1005346ac [8] std::sys_common::backtrace::__rust_begin_short_backtrace::hd6334804a2dbe4d9(0x1005345f4, 0x10, 0x2, 0x20, 0xffffffffffffff90, 0xffffffff7f5c2a10), at 0x100e861d8 [9] std::panicking::try::do_call::hd1cfde8c5dbdc033(0xffffffff7ffff280, 0x0, 0x1, 0x0, 0x0, 0x0), at 0x100e9a2e4 [10] __rust_maybe_catch_panic(0x100e9a2dc, 0xffffffff7ffff2b8, 0xffffffff7ffff320, 0xffffffff7ffff2d8, 0x10100d450, 0x0), at 0x100ea3fe4 [11] std::rt::lang_start::hf962a6d003ab04a6(0xffffffff7ffff2d8, 0x10111aac0, 0x1, 0x1, 0x1, 0xffffffff7ec1a020), at 0x100e9b9b0 [12] main(0x1, 0xffffffff7ffff4d8, 0x10100d450, 0xffffffff7ffff4d8, 0x1, 0x1), at 0x1005348c4 On intel it doesn't core dumps: $ LIBCLANG_PATH=/usr/lib/amd64/ ./target/debug/test cargo:rustc-link-lib=bz2 thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotPresent', /scratch/userland-rust/components/rust/rustc/rustc-1.21.0-src/src/libcore/result.rs:906:4 note: Run with `RUST_BACKTRACE=1` for a backtrace. (I don't think intel error is important here). Any thoughts where to look or report the issue? rust, bindgen or clang?
(In reply to Petr Sumbera from comment #10) > Any thoughts where to look or report the issue? rust, bindgen or clang? Have you verified that your version of Rust has all the fixes I previously mentioned? Without the fixes, there is no point in trying to build anything with Rust because it will segfault!
I have tested Clang fix: - https://github.com/rust-lang/llvm/pull/94 And also Rust fix: - https://github.com/rust-lang/rust/pull/45508 All with Rust 1.21. But there is no change. I wasn't able to test the last issue below since I don't see changed file in Rust 1.21. But anyway I'm able to build Rust on sparc without issue. - https://github.com/rust-lang/rust/issues/45509
I think I can rule out Bindgen now. I can get very similar crash on sparc with just clang-sys test with added call to clang_getTranslationUnitCursor(). Where the same on intel doesn't crash. git clone https://github.com/KyleMayes/clang-sys.git cd clang-sys/ LIBCLANG_PATH=/usr/lib/sparcv9 cargo build gpatch -p1 <<EOF --- a/tests/lib.rs +++ b/tests/lib.rs @@ -22,6 +22,8 @@ fn parse() { 0, ); assert!(!tu.is_null()); + + clang_getTranslationUnitCursor (tu); } } EOF LIBCLANG_PATH=/usr/lib/sparcv9 cargo test --verbose -- output -- ST-ul-cbe 14:38 /scratch: git clone https://github.com/KyleMayes/clang-sys.git remote: Compressing objects: 100% (18/18), done. remote: Total 4847 (delta 8), reused 16 (delta 7), pack-reused 4822 Receiving objects: 100% (4847/4847), 1.48 MiB | 1.38 MiB/s, done. Resolving deltas: 100% (3929/3929), done. ST-ul-cbe 14:38 /scratch: cd clang-sys/ ST-ul-cbe 14:38 /scratch/clang-sys: LIBCLANG_PATH=/usr/lib/sparcv9 cargo build Updating registry `https://github.com/rust-lang/crates.io-index` Compiling libc v0.2.33 Compiling glob v0.2.11 Compiling clang-sys v0.21.1 (file:///scratch/clang-sys) Finished dev [unoptimized + debuginfo] target(s) in 16.15 secs ST-ul-cbe 14:39 /scratch/clang-sys: gpatch -p1 <<EOF > --- a/tests/lib.rs > +++ b/tests/lib.rs > @@ -22,6 +22,8 @@ fn parse() { > 0, > ); > assert!(!tu.is_null()); > + > + clang_getTranslationUnitCursor (tu); > } > } > > EOF patching file tests/lib.rs ST-ul-cbe 14:39 /scratch/clang-sys: LIBCLANG_PATH=/usr/lib/sparcv9 cargo test --verbose Fresh glob v0.2.11 Fresh libc v0.2.33 Compiling clang-sys v0.21.1 (file:///scratch/clang-sys) Running `/scratch/clang-sys/target/debug/build/clang-sys-204a3b86205400e1/build-script-build` Running `rustc --crate-name clang_sys src/lib.rs --emit=dep-info,link -C debuginfo=2 --test -C metadata=6b937a345bcd1ac7 -C extra-filename=-6b937a345bcd1ac7 --out-dir /scratch/clang-sys/target/debug/deps -L dependency=/scratch/clang-sys/target/debug/deps --extern glob=/scratch/clang-sys/target/debug/deps/libglob-70cda51fbccaaa8d.rlib --extern libc=/scratch/clang-sys/target/debug/deps/liblibc-5cd8a2c3f81afc59.rlib -L /usr/lib/sparcv9 -l dylib=clang` Running `rustc --crate-name clang_sys src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=9fc1c56e4221f50a -C extra-filename=-9fc1c56e4221f50a --out-dir /scratch/clang-sys/target/debug/deps -L dependency=/scratch/clang-sys/target/debug/deps --extern glob=/scratch/clang-sys/target/debug/deps/libglob-70cda51fbccaaa8d.rlib --extern libc=/scratch/clang-sys/target/debug/deps/liblibc-5cd8a2c3f81afc59.rlib -L /usr/lib/sparcv9 -l dylib=clang` Running `rustc --crate-name lib tests/lib.rs --emit=dep-info,link -C debuginfo=2 --test -C metadata=0185af24ab9d337c -C extra-filename=-0185af24ab9d337c --out-dir /scratch/clang-sys/target/debug/deps -L dependency=/scratch/clang-sys/target/debug/deps --extern glob=/scratch/clang-sys/target/debug/deps/libglob-70cda51fbccaaa8d.rlib --extern libc=/scratch/clang-sys/target/debug/deps/liblibc-5cd8a2c3f81afc59.rlib --extern clang_sys=/scratch/clang-sys/target/debug/deps/libclang_sys-9fc1c56e4221f50a.rlib -L /usr/lib/sparcv9` Finished dev [unoptimized + debuginfo] target(s) in 9.94 secs Running `/scratch/clang-sys/target/debug/deps/clang_sys-6b937a345bcd1ac7` running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out Running `/scratch/clang-sys/target/debug/deps/lib-0185af24ab9d337c` running 2 tests error: process didn't exit successfully: `/scratch/clang-sys/target/debug/deps/lib-0185af24ab9d337c` (signal: 11, SIGSEGV: invalid memory reference) -- stack -- t@2 (l@2) terminated by signal SEGV (no mapping at the fault address) 0xffffffff795fe5d4: clang_getTranslationUnitCursor+0x0044: ldx [%g1 + 80], %g1 (dbx) where current thread: t@2 =>[1] clang_getTranslationUnitCursor(0xffffffff7f2ef230, 0x10036dff0, 0x0, 0x0, 0x0, 0xffffffff7c604438), at 0xffffffff795fe5d4 [2] lib::parse::hd6958de790517368(0x0, 0x1003078c0, 0xffffffff7c22f3c0, 0xffffffff7f4e0240, 0xffffffff7f4e0240, 0xff000000), at 0x1000e4cf8 [3] lib::test::hdf1f27ef6fffd9e9(0x100367130, 0x0, 0xbc00, 0xffffffff7c227948, 0xffffffff7c226000, 0x0), at 0x1000e4d14 [4] test::__rust_begin_short_backtrace::hac72d92f12c6ba2e(0x1000e4d10, 0x8, 0xffffffff7f2ef4f8, 0xffffffff7f4e0278, 0x38, 0xff000000), at 0x100168404 [5] _$LT$F$u20$as$u20$test..FnBox$LT$T$GT$$GT$::call_box::h7f11d462d5a89eca(0x100350d40, 0x100367130, 0x100350d40, 0xffffffff7f2ef4f8, 0x8, 0x0), at 0x100156a94 [6] std::panicking::try::do_call::h6c3ad48708b57aee(0x100156a88, 0x100330260, 0x0, 0x100330280, 0xffffffff7f3ef5d8, 0x0), at 0x1001418c4 [7] __rust_maybe_catch_panic(0x1001418b4, 0xffffffff7f2ef9b8, 0xffffffff7f2ef8f8, 0xffffffff7f2ef810, 0x1003078c0, 0x0), at 0x1001d5bfc [8] std::sys_common::backtrace::__rust_begin_short_backtrace::h50381cb44b8fb519(0xba0, 0x100330260, 0xffffffff7f2ef6a8, 0xffffffff7f2ef810, 0x0, 0x0), at 0x1001408dc [9] std::panicking::try::do_call::hf3c0f21e8097fa85(0xffffffff7f2efde8, 0xffffffff7f2efb48, 0x10032eae0, 0x0, 0x0, 0x0), at 0x1001418ec [10] __rust_maybe_catch_panic(0x1001418d4, 0xffffffff7f2efde8, 0xffffffff7f2efdd8, 0xffffffff7f2efde0, 0x1003078c0, 0x0), at 0x1001d5bfc [11] _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hd394069a394a8768(0xffffffff7f2efde8, 0x1003078c0, 0x100366290, 0xffffffff7f2efd50, 0xba8, 0x0), at 0x10014cb5c [12] std::sys::imp::thread::Thread::new::thread_start::h40999f9bd27b95bc(0x10014cabc, 0xffffffff7f5e4000, 0x1003682c0, 0x1003078c0, 0x0, 0x0), at 0x1001ca7a4
(In reply to Petr Sumbera from comment #12) > I have tested Clang fix: > - https://github.com/rust-lang/llvm/pull/94 You definitely need this. Otherwise Rust binaries will segfault on SPARC because of improper stack-alignment. > And also Rust fix: > - https://github.com/rust-lang/rust/pull/45508 This also needs to be in as otherwise you will see a segfault. > All with Rust 1.21. But there is no change. > > I wasn't able to test the last issue below since I don't see changed file in > Rust 1.21. But anyway I'm able to build Rust on sparc without issue. > - https://github.com/rust-lang/rust/issues/45509 It has not been changed in Rust-1.21 because the proper bugfix is more complicated. However, you can workaround this issue by disabling the packed attribute for the Span type. You need all the three fixes above, otherwise anything you compile with Rust will crash on SPARC. Did you manage to build cargo natively on Solaris-SPARC with Rust? Because I couldn't without the three patches above. Also, please verify whether your Rust build is using an external LLVM source or an internal build.
(In reply to John Paul Adrian Glaubitz from comment #14) > (In reply to Petr Sumbera from comment #12) > > All with Rust 1.21. But there is no change. > > > > I wasn't able to test the last issue below since I don't see changed file in > > Rust 1.21. But anyway I'm able to build Rust on sparc without issue. > > - https://github.com/rust-lang/rust/issues/45509 > > It has not been changed in Rust-1.21 because the proper bugfix is more > complicated. However, you can workaround this issue by disabling the packed > attribute for the Span type. I don't see src/libsyntax_pos/span_encoding.rs anywhere in Rust-1.21 source tree. > You need all the three fixes above, otherwise anything you compile with Rust > will crash on SPARC. There are definitely Rust produced binaries which can be run on sparc64 without segfault. > Did you manage to build cargo natively on Solaris-SPARC with Rust? Because I > couldn't without the three patches above. Yes I did. Do you build on Solaris? > Also, please verify whether your Rust build is using an external LLVM source > or an internal build. I'm pretty sure it build its own version of LLVM. I guess it must be asked somehow to use system one.
(In reply to Petr Sumbera from comment #15) > I don't see src/libsyntax_pos/span_encoding.rs anywhere in Rust-1.21 source > tree. Talk about moving targets :). Did you check whether the file was moved? > > You need all the three fixes above, otherwise anything you compile with Rust > > will crash on SPARC. > > There are definitely Rust produced binaries which can be run on sparc64 > without segfault. Yes, some simple binaries work when cross-compiled without the fixes. However, if you want a native, working Rust cross-compiler, you need the fixes. I have been doing lots of testing with Rust on SPARC. > > Did you manage to build cargo natively on Solaris-SPARC with Rust? Because I > > couldn't without the three patches above. > > Yes I did. Do you build on Solaris? No, on Linux SPARC. But I don't think the issue is any different on Solaris as the LLVM and Span bugs are SPARC-related. > > Also, please verify whether your Rust build is using an external LLVM source > > or an internal build. > > I'm pretty sure it build its own version of LLVM. I guess it must be asked > somehow to use system one. Are you seeing the cmake build for LLVM when you build Rust?
(In reply to John Paul Adrian Glaubitz from comment #16) > (In reply to Petr Sumbera from comment #15) > > > Also, please verify whether your Rust build is using an external LLVM source > > > or an internal build. > > > > I'm pretty sure it build its own version of LLVM. I guess it must be asked > > somehow to use system one. > > Are you seeing the cmake build for LLVM when you build Rust? I do.
So, I just checked and src/libsyntax_pos/span_encoding.rs is still there: > https://github.com/rust-lang/rust/blob/master/src/libsyntax_pos/span_encoding.rs#L23 You will need this change to fix a bus error on SPARC: > https://github.com/rust-lang/rust/pull/45679/files#diff-9500dad6d8925495533dd101a4f95d3a Can you please cross-rebuild Rust with all these three changes applied and report back? Adrian
(In reply to John Paul Adrian Glaubitz from comment #18) > So, I just checked and src/libsyntax_pos/span_encoding.rs is still there: For some reason it's not in rustc-1.21.0-src.tar.xz But yes I can see it in rustc-1.22.1-src.tar.xz So I think I will need to move to that version first.
> https://github.com/rust-lang/rust/pull/45679/files#diff-9500dad6d8925495533dd101a4f95d3a Above changed doesn't help either. Tested with Rust 1.22.1.
You should try to build cargo natively with the freshly cross-build Rust version. Only if that works, you can be sure your Rust compiler actually doesn't generate broken code.
I did build Cargo 0.23 with Rust 1.21.0. All natively on Solaris sparc. Isn't this enough?
(In reply to Petr Sumbera from comment #22) > I did build Cargo 0.23 with Rust 1.21.0. All natively on Solaris sparc. > Isn't this enough? Yeah, if you managed to build Cargo with Rust natively on Solaris-Sparc, you have all the three patches above merged. Being able to build Cargo on the SPARC means that the compiler itself works well enough. Then your issue is probably in one of the crates for Firefox.
I have now logged Rust bug with more findings: https://github.com/rust-lang/rust/issues/46679
(In reply to Petr Sumbera from comment #24) > I have now logged Rust bug with more findings: > https://github.com/rust-lang/rust/issues/46679 Thanks for filing this. FWIW, I also did some testing with the current Rust git snapshot as of three days ago: > https://github.com/rust-lang/rust/issues/45509#issuecomment-350516305 I still had to add the LLVM patch as otherwise the cross-compiled Rust compiler would just segfault. With the patch added, it works, but a simple compiled "hello.rs" crashes with a Bus Error.
I'm closing this as it's rust issue (see above comment for rust bug).
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.