Cargo build crashes with SIGKILL

Everything was working correctly until I did some code changes and now when compiling with cargo build, I get this:

error: could not compile `orwell_gtk`.

Caused by:
  process didn't exit successfully: `rustc --crate-name orwell_gtk --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=ca4bbb4304591f7c -C extra-filename=-ca4bbb4304591f7c --out-dir /home/dev/orwell/lab/orwell_gtk/target/debug/deps -C incremental=/home/dev/orwell/lab/orwell_gtk/target/debug/incremental -L dependency=/home/dev/orwell/lab/orwell_gtk/target/debug/deps --extern epoxy=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libepoxy-8fe564a3467e793b.rlib --extern gdk=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libgdk-50da2c03bd6f3281.rlib --extern gio=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libgio-c43bc334650414d1.rlib --extern gl=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libgl-163c56533c6a78e4.rlib --extern gtk=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libgtk-186ddbba2242cdaf.rlib --extern libc=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/liblibc-08daa819fd8f974b.rlib --extern liborwell_rust=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libliborwell_rust-a85585b253215608.rlib --extern shared_library=/home/dev/orwell/lab/orwell_gtk/target/debug/deps/libshared_library-bf0d2e688fd807df.rlib -L native=/usr/lib/x86_64-linux-gnu -L /usr/lib/x86_64-linux-gnu/ -L native=/home/dev/orwell/deps/ffmpeg/build/linux/x86_64/lib -L /usr/lib/x86_64-linux-gnu/` (signal: 9, SIGKILL: kill)

When using VSCode, the intellisense starts running and blocks the entire VM, and then I have to close it.

I deleted the target folder. I then run cargo build and it builds the dependencies but when it starts to build my project everything freezes again and the notebook starts getting hot.

Any ideas on how to debug this?

Is it possible that you're low on RAM? Your kernel's OOM killer might be killing rustc...

I have 8gb and opened only the project to compile on terminal, not even vscode opened.

I traced the problem to this line:

changing

                            gl::BufferData(
                                gl::PIXEL_UNPACK_BUFFER,
                                texture_size[i as usize],
                                ffmpeg_decoded_packet.data(i.into()).as_ptr() as *mut libc::c_void,
                                gl::STREAM_DRAW,
                            );

to

                            gl::BufferData(
                                gl::PIXEL_UNPACK_BUFFER,
                                (texture_size[i as usize] as usize * std::mem::size_of::<f32>()) as isize
                                ffmpeg_decoded_packet.data(i.into()).as_ptr() as *const libc::c_void,
                                gl::STREAM_DRAW,
                            );

makes the crash happen. Problem is in this line (texture_size[i as usize] as usize * std::mem::size_of::<f32>()) as isize. With texture_size[i as usize], it does not crash

It sounds like a bug in the compiler might be causing it to go into an infinite loop and use more and more memory until it gets killed.

If it is a compiler bug, one useful first step is to check which versions it affects. Does it show up if you use the latest beta or nightly toolchain? How about an older stable toolchain? Once you know roughly what version(s) are affected, you could report it to the Rust issue tracker, and/or use cargo-bisect-rustc to narrow down the regression range even further.

hey, it's for sure a bug, just found out:

 gl::BufferData(
                                gl::PIXEL_UNPACK_BUFFER,
                                (texture_size[i as usize] as usize * std::mem::size_of::<f32>()) as isize
                                ffmpeg_decoded_packet.data(i.into()).as_ptr() as *const libc::c_void,
                                gl::STREAM_DRAW,
                            );

the missing comma on (texture_size[i as usize] as usize * std::mem::size_of::<f32>()) as isize causes this. With the comma everything works ok.

rustc 1.46.0 (04488afe3 2020-08-24)

3 Likes

Unfortunately my project is too big to post. I cloned a simple project on github that uses gl::BufferData and took out the comma: https://github.com/vigostudio/rust2dFlappyBird/blob/d6f01ae7c25c9f6866a580e109e0be1846f63f07/src/main.rs#L67 but couldn't reproduce the problem. Here it simply complains about the missing comma:

error: expected one of `!`, `(`, `)`, `,`, `.`, `::`, `<`, or `?`, found `vertices`
  --> src/main.rs:68:13
   |
67 |               (vertices.len() * std::mem::size_of::<f32>()) as gl::types::GLsizeiptr
   |                                                                                     - expected one of 8 possible tokens
   |  ___________________________________________________________________________________|
   | |
68 | |             vertices.as_ptr() as *const gl::types::GLvoid, // pointer to data
   | | |           ^^^^^^^^ unexpected token

The following seems to be a minimal test case. Note that lines 3 and 4 must have at least 29 columns of leading whitespace in order to reproduce the bug.

fn main() {
    (
                             0
                             0 as u8);
}
7 Likes

Ok, I give up. How on earth did you ever come up with that example? :smiley:

3 Likes

I took the code from the example above, pasted it into a main function, and found that I was able to reproduce the problem. Then I removed and simplified pieces of it until I couldn't reduce it any further. :slight_smile:

2 Likes

After updating to the latest nightly, I can no longer reproduce the problem. I haven't yet bisected to find out when it was fixed, but it looks like it was within the past month or so.

I can reproduce the bug in:

  • rustc 1.47.0-beta.3 (aa30bf344 2020-09-10)
  • rustc 1.48.0-nightly (e2be5f568 2020-09-09)

But not in:

  • rustc 1.47.0 (18bf6b4f0 2020-10-07)
  • rustc 1.49.0-nightly (c71248b70 2020-10-11)

So the fix must have been backported to the 1.47 branch.

1 Like

Looks like it was this bug, which is fixed in Rust 1.47.0:

5 Likes