cargo clippy with clippy-preview crash on x86 Linux #3345

therealbstern · 2018-10-20T22:20:44Z

$ rustc --version
rustc 1.29.2 (17a9dc751 2018-10-05)
$ cargo clippy -V
0.0.212

Line-wrapped output (for viewing convenience; irrelevant path specs replaced with ...). [In real life, the "Caused by" lines are one long line all the way through the end of the SIGSEGV.]

error: Could not compile `byte-tools`.
Caused by:
  process didn't exit successfully: `/usr/local/bin/clippy-driver rustc --crate-name
    byte_tools .../.cargo/registry/src/github.com-1ecc6299db9ec823/byte-tools-0.2.0/src/lib.rs
    --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C metadata=5da25c9bb6e69df5 -C
    extra-filename=-5da25c9bb6e69df5 --out-dir .../target/debug/deps -L
    dependency=.../target/debug/deps --cap-lints allow`
(signal: 11, SIGSEGV: invalid memory reference)

error: Could not compile `byteorder`.
Caused by:
  process didn't exit successfully: `/usr/local/bin/clippy-driver rustc --crate-name
    byteorder .../.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-1.2.4/src/lib.rs
    --crate-type lib --emit=dep-info,metadata -C debuginfo=2 --cfg 'feature="default"' --cfg
    'feature="std"' -C metadata=9166e152500d52e7 -C extra-filename=-9166e152500d52e7 --out-dir
    .../target/debug/deps -L dependency=.../target/debug/deps --cap-lints allow`
(signal: 11, SIGSEGV: invalid memory reference)

This is reproducible. It happens regardless of the status of cargo clean; i.e., if I do issue cargo clean; cargo clippy it happens, and if I do cargo build; cargo clippy it happens. (Note that my build succeeds).

Please let me know if you need any additional information.

The text was updated successfully, but these errors were encountered:

matthiaskrgr · 2018-10-22T19:37:36Z

Hmm. I tried checking the bytetools https://github.com/RustCrypto/utils/tree/master/byte-tools crate with clippy on nightly, beta and stable but could not repro any crash.

therealbstern · 2018-10-23T02:05:18Z

~~Hmm. I'm on Linux 32-bit. Are you? I did forget that from my original report - I apologize.~~ (In the title, my mistake.)

I'll test with byte-tools directly and report back.

therealbstern · 2018-10-23T02:28:23Z

This seems to happen to me with byte-tools 0.2.0. I'll see whether my project can trivially upgrade to 0.3.0, but clippy probably shouldn't segfault anyway.

Line-wrapped for clarity:

~/.cargo/registry/src/github.com-1ecc6299db9ec823/byte-tools-0.2.0$ cargo clippy --verbose
    Checking byte-tools v0.2.0 (file://[...]/byte-tools-0.2.0)                         
     Running `/usr/local/bin/clippy-driver rustc --crate-name byte_tools src/lib.rs
       --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C
       metadata=32680534df867787 -C extra-filename=-32680534df867787 --out-dir
       [...]/target/debug/deps -C incremental=[...]/target/debug/incremental -L
       dependency=[...]/target/debug/deps`
error: Could not compile `byte-tools`.

Caused by:
  process didn't exit successfully: `[all the same stuff just above]`
    (signal: 11, SIGSEGV: invalid memory reference)

~/.cargo/registry/src/github.com-1ecc6299db9ec823/byte-tools-0.2.0$ uname -imprvs
Linux 4.4.153-smp #2 SMP [...] i686 Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz GenuineIntel

Is there any additional information that I can provide?

hcpl · 2018-10-23T02:47:12Z

From what I've seen, clippy for 32-bit targets are either not tested enough to run without fail or not supported at all, because clippy does not work on i686-pc-windows-{gnu,msvc} and quoting myself from that comment:

32-bit tests are broken in general. Travis never runs these so the failures don't matter there.

AIUI, this means that 32-bit clippy shipped via rustup is only built, but has never run (any tests) at all.

EDIT: or this means that 32-bit clippy cannot be run on 64-bit Windows (and vice versa) which sounds more plausible to me.

This is all pure speculation and I haven't tested my claim for 32-bit Unixes, so take my words with a grain of salt.

EDIT: also SIGSEGV on Linux is likely to be the equivalent of exit code 3221225477 == 0xC0000005 == access violation on Windows.

therealbstern · 2018-10-23T03:27:36Z

Re: "Access Violation": yes, I believe they are the same thing.

If clippy is broken on 32-bit and that's okay,

I understand, and closing this issue is a reasonable reaction,
but perhaps it should not be included in 32-bit releases of Rust, or on any platforms that it is expected to fail upon,
though on the gripping hand, if the intent is to shake out these failures on other platforms, then chasing this further might be of benefit.

therealbstern · 2018-10-23T03:52:27Z

I kicked clippy a little more and got a backtrace:

byte-tools-0.2.0$ gdb cargo
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cargo...done.
(gdb) set follow-exec-mode new
(gdb) set detach-on-fork off
(gdb) show follow-fork-mode
Debugger response to a program call of fork or vfork is "parent".
(gdb) set follow-fork-mode child
(gdb) run clippy --verbose
Starting program: /usr/local/bin/cargo clippy --verbose
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
process 12125 is executing new program: /usr/local/bin/cargo-clippy
[New process 12125]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New process 12129]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
process 12129 is executing new program: /usr/local/bin/cargo
[New process 12129]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb77ffb40 (LWP 12130)]
[New Thread 0xb73ffb40 (LWP 12131)]
    Checking byte-tools v0.2.0 ([...].byte-tools-0.2.0)
     Running `/usr/local/bin/clippy-driver rustc --crate-name byte_tools src/lib.rs
       --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C
      metadata=32680534df867787 -C extra-filename=-32680534df867787 --out-dir
      [...]/target/debug/deps -C incremental=[...]/target/debug/incremental -L
      dependency=[...]/target/debug/deps`
[New process 12132]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
process 12132 is executing new program: /usr/local/bin/clippy-driver
[New process 12132]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New process 12133]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
process 12133 is executing new program: /usr/local/bin/rustc
Reading symbols from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so...done.
Reading symbols from /usr/local/bin/../lib/librustc-803d08957e6359cf.so...done.
Reading symbols from /usr/local/bin/../lib/librustc_data_structures-64688dc184c72a76.so...done.
Reading symbols from /usr/local/bin/../lib/libstd-2f004764056eda78.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_codegen_utils-5f869f8aed6a721d.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_save_analysis-611e72632f2e7117.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_incremental-947417a5241cc107.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_mir-f72f626c19579c1d.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/libtest-37d49a8ff37bb238.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/libserialize-55417a241a47e1db.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/../lib/libterm-3b72c6a6d17b52fc.so...done.
[New process 12133]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[Inferior 8 (process 12133) exited normally]
(gdb) info inferiors
  Num  Description       Executable
  1    <null>            /usr/local/bin/cargo
  2    process 12125     /usr/local/bin/cargo-clippy
  4    process 12129     /usr/local/bin/cargo
  6    process 12132     /usr/local/bin/clippy-driver
* 8    <null>            /usr/local/bin/rustc
(gdb) inf
inferior  info
(gdb) inferior 6
[Switching to inferior 6 [process 12132] (/usr/local/bin/clippy-driver)]
[Switching to thread 6.1 (Thread 0xb4f35900 (LWP 12132))]
#0  0xb6217f51 in fork () from /lib/libc.so.6
(gdb) continue
Continuing.
[New Thread 0xb1817b40 (LWP 12162)]
[Thread 0xb1817b40 (LWP 12162) exited]
[New process 12163]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
process 12163 is executing new program: /usr/local/bin/cargo
Reading symbols from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so...done.
Reading symbols from /usr/local/bin/../lib/librustc-803d08957e6359cf.so...done.
Reading symbols from /usr/local/bin/../lib/librustc_data_structures-64688dc184c72a76.so...done.
Reading symbols from /usr/local/bin/../lib/libstd-2f004764056eda78.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_codegen_utils-5f869f8aed6a721d.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_save_analysis-611e72632f2e7117.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_incremental-947417a5241cc107.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/librustc_mir-f72f626c19579c1d.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/libtest-37d49a8ff37bb238.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/libserialize-55417a241a47e1db.so...done.
Reading symbols from /usr/local/bin/../lib/../lib/../lib/libterm-3b72c6a6d17b52fc.so...done.
Reading symbols from /usr/local/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so...done.
[New process 12163]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[Inferior 10 (process 12163) exited normally]
(gdb) info inferiors
  Num  Description       Executable
  1    <null>            /usr/local/bin/cargo
  2    process 12125     /usr/local/bin/cargo-clippy
  4    process 12129     /usr/local/bin/cargo
  6    process 12132     /usr/local/bin/clippy-driver
  8    <null>            /usr/local/bin/rustc
* 10   <null>            /usr/local/bin/cargo
(gdb) inferior 6
[Switching to inferior 6 [process 12132] (/usr/local/bin/clippy-driver)]
[Switching to thread 6.1 (Thread 0xb4f35900 (LWP 12132))]
#0  0xb6217f51 in fork () from /lib/libc.so.6
(gdb)
[Switching to inferior 6 [process 12132] (/usr/local/bin/clippy-driver)]
[Switching to thread 6.1 (Thread 0xb4f35900 (LWP 12132))]
#0  0xb6217f51 in fork () from /lib/libc.so.6
(gdb) continue
Continuing.

Thread 6.1 "clippy-driver" received signal SIGSEGV, Segmentation fault.
0x00590adf in _$LT$clippy_lints..returns..ReturnPass$u20$as$u20$rustc..lint..EarlyLintPass$GT$::check_block::ha6aa870b73fc15d6 ()
(gdb) bt
#0  0x00590adf in _$LT$clippy_lints..returns..ReturnPass$u20$as$u20$rustc..lint..EarlyLintPass$GT$::check_block::ha6aa870b73fc15d6 ()
#1  0xb74e8a3f in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_block::hb2436b252d4dc7b0 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#2  0xb6e7eede in syntax::visit::walk_expr::h7bc7ae2cbcb8be07 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#3  0xb74e6d64 in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_expr::h1c6ae7dbe521c414 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#4  0xb6e82ab8 in syntax::visit::walk_stmt::hb125825f5119f593 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#5  0xb74e8b3d in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_block::hb2436b252d4dc7b0 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#6  0xb6e7edd1 in syntax::visit::walk_expr::h7bc7ae2cbcb8be07 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#7  0xb74e6d64 in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_expr::h1c6ae7dbe521c414 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#8  0xb6e82ab8 in syntax::visit::walk_stmt::hb125825f5119f593 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#9  0xb74e8b3d in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_block::hb2436b252d4dc7b0 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#10 0xb6e7eede in syntax::visit::walk_expr::h7bc7ae2cbcb8be07 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#11 0xb74e6d64 in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_expr::h1c6ae7dbe521c414 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#12 0xb6e82ab8 in syntax::visit::walk_stmt::hb125825f5119f593 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#13 0xb74e8b3d in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_block::hb2436b252d4dc7b0 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#14 0xb6e7a359 in syntax::visit::walk_fn::h4960770f1541328c () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#15 0xb74e7209 in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_fn::h95af3b5ab98fd0c8 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#16 0xb6e8240d in syntax::visit::walk_item::hdc16ab0c6bc30763 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#17 0xb74e641e in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_item::hd51921034e3befb4 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#18 0xb74e84fe in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_mod::h9a3d834787d83c51 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#19 0xb6e82437 in syntax::visit::walk_item::hdc16ab0c6bc30763 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#20 0xb74e641e in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_item::hd51921034e3befb4 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#21 0xb74e84fe in _$LT$rustc..lint..context..EarlyContext$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$a$GT$$GT$::visit_mod::h9a3d834787d83c51 () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#22 0xb74eb798 in rustc::lint::context::check_ast_crate::h09a610a2cc4f561c () from /usr/local/bin/../lib/librustc-803d08957e6359cf.so
#23 0xb7df0387 in rustc::util::common::time::h597b59de9d0dd1c6 () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#24 0xb7de1c72 in rustc_driver::driver::phase_2_configure_and_expand::hb03d160f49ecf55e ()
   from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#25 0xb7ddc088 in rustc_driver::driver::compile_input::h309fce5a01e61835 () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#26 0xb7e917a2 in rustc_driver::run_compiler_with_pool::hd9ecd1282f1ae6db () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#27 0xb7da099a in _$LT$scoped_tls..ScopedKey$LT$T$GT$$GT$::set::h7903e06ad2cd8b6d () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#28 0xb7da0669 in _$LT$scoped_tls..ScopedKey$LT$T$GT$$GT$::set::h6ce628e67dc9eb8d () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#29 0xb7e42f8f in syntax::with_globals::h0ecbf7da16de1b06 () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so
#30 0xb7e907a8 in rustc_driver::run_compiler::hf2535f8905c2e2de () from /usr/local/bin/../lib/librustc_driver-7347af2c9cdaca0e.so                       
#31 0x0044e980 in clippy_driver::main::h7d2ad413b1815726 ()
#32 0x0043a146 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h948d4b5b2bb6bda8 ()
#33 0xb63d80be in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h02a833680b7f2e42 () at libstd/rt.rs:59
#34 std::sys_common::backtrace::__rust_begin_short_backtrace::ha0d8ae30e78f33e6 () at libstd/sys_common/backtrace.rs:136
#35 0xb63d0ca2 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hc407efd21fbbb227 () at libstd/rt.rs:59
#36 std::panicking::try::do_call::hadd24133eee93c2a () at libstd/panicking.rs:310
#37 0xb6415528 in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#38 0xb63d0c06 in std::panicking::try::ha5043ce4d03a4ab3 () at libstd/panicking.rs:289
#39 0xb63d6385 in std::panic::catch_unwind::h1cf979638beb9551 () at libstd/panic.rs:392
#40 std::rt::lang_start_internal::h6bbe1a2cc9111404 () at libstd/rt.rs:58`
#41 0x0044fb71 in main ()
(gdb) cont
Continuing.

Thread 6.1 "clippy-driver" received signal SIGSEGV, Segmentation fault.
0x00590adf in _$LT$clippy_lints..returns..ReturnPass$u20$as$u20$rustc..lint..EarlyLintPass$GT$::check_block::ha6aa870b73fc15d6 ()
(gdb) cont
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

therealbstern · 2018-10-23T03:58:26Z

As predicted, I can cargo clippy byte-tools 0.2.0 all day long on 64-bit.

hcpl · 2018-10-23T04:28:15Z

So from this stacktrace (thanks @therealbstern!) this method segfaults:

https://github.com/rust-lang-nursery/rust-clippy/blob/48cb6e273ea49e85b6baa209e0123a2bbd6d15c2/clippy_lints/src/returns.rs#L146-L148

That was the latest commit to this file which precedes the release of clippy 0.0.212 (2018-07-07 according to crates.io). Git blame of the check_let_return method shows that it wasn't modified at all except some cosmetic changes since the release. So probably check_let_return is the one that needs a fix.

phansch · 2018-10-27T18:23:02Z

Thanks for the investigation!
I'm going to try and reproduce this on a 32bit Docker image and see if that can be integrated into CI.

phansch · 2018-10-27T21:01:44Z

I managed to set up a 32bit docker container to run Clippy on byte-tools:
https://gist.github.com/phansch/39baf111d6f5fa4c4c44b3ba8ab4f559

It's currently set to check RustCrypto/utils@12b85f9#diff-680d0fd529aaf10e64df6cd0feb785ea but doesn't cause a crash. I ran out of time for today and will check the other commits tomorrow.

phansch · 2018-10-28T07:58:48Z

I can't reproduce the crash with the docker container. Maybe because my host system is 64 bit? I'm going to try it with a Vagrant VM next.

hcpl · 2018-10-28T08:02:13Z

Maybe because my host system is 64 bit?

I think the answer is yes --- I tried to reproduce with qemu-i386 on my 64-bit laptop but couldn't as well.

phansch · 2018-10-28T12:04:26Z

I also can't seem to reproduce it with a Vagrant VM.
This is the Vagrantfile I used: https://gist.github.com/phansch/39baf111d6f5fa4c4c44b3ba8ab4f559#file-vagrantfile

@therealbstern Could you also provide the output of lscpu or cat /proc/cpuinfo?

hcpl · 2018-10-28T18:00:45Z

cc #2310

therealbstern · 2018-10-29T03:03:12Z

Line-wrapped for convenience:

$ lscpu 
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Model name:            Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
Stepping:              3
CPU MHz:               3502.187
CPU max MHz:           3900.0000
CPU min MHz:           800.0000
BogoMIPS:              6996.07
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
  pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc
  arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
  ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt
  tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi
  flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
  dtherm ida arat pln pts

mcandre · 2018-11-03T06:45:18Z

From what I've seen, clippy for 32-bit targets are either not tested enough to run without fail or not supported at all

This does not bode well for MINIX support

mati865 · 2018-11-03T22:46:48Z

Sorry for lengthy comment but I'd appreciate if somebody could verify my uneducated "debugging", I'm testing with byte-tools repo mentioned above.

I was able to create overly complicated environment which reproduces the error and after some digging SIGSEGV happens here:
https://github.com/rust-lang-nursery/rust-clippy/blob/62568923d5c949fc09eb84330ea352eca3e50870/clippy_lints/src/returns.rs#L159-L160

Clippy release builds on 32 bit Linux crash when anything tries to use local, debug builds return early on if let ast::StmtKind::Local(ref local) = stmt.node; without crashing. Release builds go past this if and fail because the pointer is invalid.

Let's see what println("dbg{:?}", stmt) gives us after disabling all lines where local was used:

Debug

dbg
stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};)

Release

dbg
stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};)
dbg
error: Could not compile `byte-tools`.
[...] SIGSEGV

One more Stmt slipped through if let Some(stmt) = it.next_back(); in release build.

Let's dump it from line 153 with println!("{:?}", it):

It's the same for both builds, click here to reveal

Iter([stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};), stmt(141: unsafe {
    ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), src.len());
})])
Iter([stmt(138: {
    ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                         "byte-tools/src/lib.rs", 9u32, 5u32))
})])
Iter([stmt(137: ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                     "byte-tools/src/lib.rs", 9u32, 5u32));)])
Iter([stmt(139: ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), src.len());)])
Iter([stmt(143: unsafe { ptr::write_bytes(dst.as_mut_ptr(), 0, dst.len()); })])
Iter([stmt(142: ptr::write_bytes(dst.as_mut_ptr(), 0, dst.len());)])
Iter([stmt(145: unsafe { ptr::write_bytes(dst.as_mut_ptr(), value, dst.len()); })])
Iter([stmt(144: ptr::write_bytes(dst.as_mut_ptr(), value, dst.len());)])

Release did not crash because `println!` consumed iterator.

Okay what if we disable lines 159-168 and just put println("dbg{:?}", it.next_back()) below:

Debug

dbg
Some(stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};))
dbg
None
dbg
None
dbg
None
dbg
None

Release

dbg
Some(stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};))
dbg
error: Could not compile `byte-tools`.
[...] SIGSEGV

😨 Looks like 2nd it.next_back(); (line 159) returns invalid pointers.

I'll see tomorrow if I can find easy way to create environment like this for anybody to try.

oli-obk · 2018-11-03T23:19:13Z

why is the Some missing in release mode? There's some truly funky stuff going on here.

These are regular slice iterators. Either the corruption happens way before this iteration and this is just a deterministic symptom, or slice iterators are broken.

mati865 · 2018-11-03T23:51:40Z

That's odd, possibly I accidentally dropped them when cleaning up output from irrelevant prints. niedz., 4 lis 2018, 00:19: Oliver S̶c̶h̶n̶e̶i̶d̶e̶r Scherer < notifications@github.com> napisał(a):

…

why is the Some missing in release mode? There's some truly funky stuff going on here. These are regular slice iterators. Either the corruption happens way before this iteration and this is just a deterministic symptom, or slice iterators are broken. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3345 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHsdgCrJcN18WKGXLDJAH8tOjczMa-Tks5uriRxgaJpZM4XyKYR> .

mati865 · 2018-11-04T09:36:36Z

Okay I fixed the output.

println!("dbg\n{:?}", it); in line 170 with all ifs disabled:

dbg
Iter([stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};), stmt(141: unsafe {
    ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), src.len());
})])
dbg
Iter([stmt(138: {
    ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                         "byte-tools/src/lib.rs", 9u32, 5u32))
})])
dbg
Iter([stmt(137: ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                     "byte-tools/src/lib.rs", 9u32, 5u32));)])
dbg
Iter([stmt(139: ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), src.len());)])
dbg
Iter([stmt(143: unsafe { ptr::write_bytes(dst.as_mut_ptr(), 0, dst.len()); })])
dbg
Iter([stmt(142: ptr::write_bytes(dst.as_mut_ptr(), 0, dst.len());)])
dbg
Iter([stmt(145: unsafe { ptr::write_bytes(dst.as_mut_ptr(), value, dst.len()); })])
dbg
Iter([stmt(144: ptr::write_bytes(dst.as_mut_ptr(), value, dst.len());)])

The same print with if let Some(retexpr) = it.next_back(); uncommented:

dbg
Iter([stmt(140: if !(dst.len() >= src.len()) {
    {
        ::panicking::panic(&("assertion failed: dst.len() >= src.len()",
                             "byte-tools/src/lib.rs", 9u32, 5u32))
    }
};)])
dbg
Iter([])
dbg
Iter([])
dbg
Iter([])
dbg
Iter([])
dbg
Iter([])
dbg
Iter([])
dbg
Iter([])

mati865 · 2018-11-04T16:49:15Z

Unfortunately I couldn't make reproducer for Linux host systems, the only thing that worked is Docker for Windows with Hyper-V (requires Windows 10 Enterprise, Pro, or Education and compatible CPU).

Run this in Powershell:

docker run -it 32bit/ubuntu:16.04 bash
apt update
apt install curl git

# It will default to x86_64-unknown-linux-gnu, type i686-unknown-linux-gnu instead
curl https://sh.rustup.rs -sSf | sh

In this container Clippy in release mode deterministically causes SIGSEGV.

mati865 · 2018-12-07T09:52:23Z

I bet it's rust-lang/rust#52026

mati865 · 2018-12-13T21:25:50Z

Yep that was the issue, going to be fixed via rust-lang/rust#56781

mati865 · 2018-12-17T00:06:36Z

Should be fixed with the next nightly.

flip1995 · 2018-12-18T13:36:05Z

So this should be fixed now. Feel free to reopen if this issue comes up again.

phansch self-assigned this Oct 27, 2018

phansch added the I-ICE Issue: Clippy panicked, giving an Internal Compilation Error (ICE) ❄️ label Oct 27, 2018

hcpl mentioned this issue Nov 3, 2018

Trouble with cygwin #3403

Closed

phansch removed their assignment Nov 22, 2018

mati865 mentioned this issue Dec 7, 2018

could not compiler winapi #3505

Closed

mati865 mentioned this issue Dec 17, 2018

Access violation exception with nightly-msvc (x86 only) #2310

Closed

mati865 mentioned this issue Dec 17, 2018

cargo clippy with clippy-preview not working with stable-i686-pc-windows-msvc (exit code 3221225477) #3202

Closed

flip1995 closed this as completed Dec 18, 2018

mati865 mentioned this issue Jan 10, 2019

Segfault during clippy lint (SIGSEGV, invalid memory reference; armv7 32bit toolchain) rust-lang/rust#51397

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cargo clippy with clippy-preview crash on x86 Linux #3345

cargo clippy with clippy-preview crash on x86 Linux #3345

therealbstern commented Oct 20, 2018

matthiaskrgr commented Oct 22, 2018

therealbstern commented Oct 23, 2018 •

edited

Loading

therealbstern commented Oct 23, 2018

hcpl commented Oct 23, 2018 •

edited

Loading

therealbstern commented Oct 23, 2018

therealbstern commented Oct 23, 2018 •

edited

Loading

therealbstern commented Oct 23, 2018 •

edited

Loading

hcpl commented Oct 23, 2018 •

edited

Loading

phansch commented Oct 27, 2018 •

edited

Loading

phansch commented Oct 27, 2018

phansch commented Oct 28, 2018

hcpl commented Oct 28, 2018

phansch commented Oct 28, 2018

hcpl commented Oct 28, 2018

therealbstern commented Oct 29, 2018

mcandre commented Nov 3, 2018

mati865 commented Nov 3, 2018 •

edited

Loading

oli-obk commented Nov 3, 2018

mati865 commented Nov 3, 2018 via email

mati865 commented Nov 4, 2018

mati865 commented Nov 4, 2018

mati865 commented Dec 7, 2018

mati865 commented Dec 13, 2018

mati865 commented Dec 17, 2018

flip1995 commented Dec 18, 2018

cargo clippy with clippy-preview crash on x86 Linux #3345

cargo clippy with clippy-preview crash on x86 Linux #3345

Comments

therealbstern commented Oct 20, 2018

matthiaskrgr commented Oct 22, 2018

therealbstern commented Oct 23, 2018 • edited Loading

therealbstern commented Oct 23, 2018

hcpl commented Oct 23, 2018 • edited Loading

therealbstern commented Oct 23, 2018

therealbstern commented Oct 23, 2018 • edited Loading

therealbstern commented Oct 23, 2018 • edited Loading

hcpl commented Oct 23, 2018 • edited Loading

phansch commented Oct 27, 2018 • edited Loading

phansch commented Oct 27, 2018

phansch commented Oct 28, 2018

hcpl commented Oct 28, 2018

phansch commented Oct 28, 2018

hcpl commented Oct 28, 2018

therealbstern commented Oct 29, 2018

mcandre commented Nov 3, 2018

mati865 commented Nov 3, 2018 • edited Loading

oli-obk commented Nov 3, 2018

mati865 commented Nov 3, 2018 via email

mati865 commented Nov 4, 2018

mati865 commented Nov 4, 2018

mati865 commented Dec 7, 2018

mati865 commented Dec 13, 2018

mati865 commented Dec 17, 2018

flip1995 commented Dec 18, 2018

therealbstern commented Oct 23, 2018 •

edited

Loading

hcpl commented Oct 23, 2018 •

edited

Loading

therealbstern commented Oct 23, 2018 •

edited

Loading

therealbstern commented Oct 23, 2018 •

edited

Loading

hcpl commented Oct 23, 2018 •

edited

Loading

phansch commented Oct 27, 2018 •

edited

Loading

mati865 commented Nov 3, 2018 •

edited

Loading