Segmentation fault when re-building

[dalibor]

It builds without error on first rake build run, but then I get segmentation fault on the following rake build runs. Error dissapears when I run rake clobber before each run to clean stuff. Even when segmentation fault error shows, it looks like it's doing a good build. It seems to be consistently happening across all Ruby versions for me and is caused by the require of native.so.

Output for ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]:

$ rake build
Building hello_world
{}
cargo rustc --release -- -C link-args=-Wl,-undefined,dynamic_lookup
    Finished release [optimized] target(s) in 0.0 secs
[BUG] Segmentation fault at 0x00000000003780
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]

-- Machine register context ------------------------------------------------
 RIP: 0x0000000000003780 RBP: 0x00007ffda040a440 RSP: 0x00007ffda040a228
 RAX: 0x00007fec25490e18 RBX: 0x00007fec2fb76180 RCX: 0x0000000000000000
 RDX: 0x0000000000000000 RDI: 0x00007fec25693040 RSI: 0x0000000000000000
  R8: 0x0000000000000000  R9: 0x00007fec2bdabe88 R10: 0x00007fec25693038
 R11: 0x00007fec2ba234a0 R12: 0x00007fec2548f848 R13: 0x000000000000002c
 R14: 0x0000000000000000 R15: 0x00007ffda040a230 EFL: 0x0000000000010202

-- C level backtrace information -------------------------------------------
Segmentation fault (core dumped)

Output for ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]:

$ rake build
Building hello_world
{}
cargo rustc --release -- -C link-args=-Wl,-undefined,dynamic_lookup
    Finished release [optimized] target(s) in 0.0 secs
[BUG] Segmentation fault at 0x00000000003780
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]

-- Machine register context ------------------------------------------------
 RIP: 0x0000000000003780 RBP: 0x00007ffca715fd80 RSP: 0x00007ffca715fb68
 RAX: 0x00007fc61006de18 RBX: 0x00007fc61b3d0200 RCX: 0x0000000000000000
 RDX: 0x0000000000000000 RDI: 0x00007fc61049a4e8 RSI: 0x0000000000000000
  R8: 0x0000000000000000  R9: 0x00007fc6165c2e88 R10: 0x00007fc61049a1c0
 R11: 0x00007fc61623a4a0 R12: 0x00007fc61006c848 R13: 0x000000000000002c
 R14: 0x0000000000000000 R15: 0x00007ffca715fb70 EFL: 0x0000000000010202

-- C level backtrace information -------------------------------------------
Segmentation fault (core dumped)

Output for ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]:

$ rake build
Building text_transform
{}
cargo rustc --release -- -C link-args=-Wl,-undefined,dynamic_lookup
    Finished release [optimized] target(s) in 0.0 secs
[BUG] Segmentation fault at 0x00000000003720
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]

-- C level backtrace information -------------------------------------------
Segmentation fault (core dumped)

[silasb]

I think the issue has to deal with the fact that we've loaded the library in memory when we run rake build in the parent project.

Might be able to fix this by not loading the entire application when our rake build happens, but the default Rakefile looks like this:

require_relative 'config/application'

Rails.application.load_tasks

so that might be rather difficult...

You can see that native.so is loaded by printing out $" after the ParentBuildTask#build loop.

[silasb]

Issue is with copy_native. We copy over the native library when it's already loaded.

[wagenet]

Ah interesting, we've done a lot of our active testing on macOS which behaves a bit differently in this area. Probably the solution would be to detect the rake build happening and avoid loading the native extension in this case, if that is feasible.

[aep]

is there a temporary workaround that doesnt involve rebuilding everything? my rust crate is rather large

[moosingin3space]

Confirmed on Ruby 2.2, Rails 3.2 on Debian Jessie.