Skip to content

[rand] Program segfaults, jemalloc worst hit #30919

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
MagaTailor opened this issue Jan 14, 2016 · 6 comments
Closed

[rand] Program segfaults, jemalloc worst hit #30919

MagaTailor opened this issue Jan 14, 2016 · 6 comments
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state

Comments

@MagaTailor
Copy link

The crash happens on ARM Linux, solely with a binary from a jemalloc enabled rustc. I normally use rustc builds that rely on pure system allocation so I had no idea the problem was there.

$ gdb --args target/debug/bfc sample_programs/hello_world.bf

Program received signal SIGSEGV, Segmentation fault.
0x7f6a3778 in rand::cell::Cell<T>::get (self=0x1) at ../src/libcore/cell.rs:195
195     ../src/libcore/cell.rs: No such file or directory.
(gdb) bt
#0  0x7f6a3778 in rand::cell::Cell<T>::get (self=0x1) at ../src/libcore/cell.rs:195
#1  0x7f6a3750 in rand::rc::RcBoxPtr::strong<alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (self=0xb6ff87d8)
    at ../src/liballoc/rc.rs:875
#2  0x7f6a34d8 in rand::rc::RcBoxPtr::inc_strong<alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (self=0xb6ff87d8)
    at ../src/liballoc/rc.rs:880
#3  0x7f6a3460 in rand::rc::Rc<T>.Clone::clone (self=0xb6ff87d8) at ../src/liballoc/rc.rs:491
#4  0x7f6a3a84 in fnfn (t=0xb6ff87d8) at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/rand-0.3.11/src/lib.rs:873
#5  0x7f6a3894 in rand::thread::local::LocalKey<T>::with<closure,alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (
    self=0x804a68fc <thread_rng::THREAD_RNG_KEY::h9f347077ce08d3aapgf>, f=...) at ../src/libstd/thread/local.rs:191
#6  0x7f6a37bc in rand::thread_rng () at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/rand-0.3.11/src/lib.rs:873
#7  0x7f69a678 in tempfile::util::tmpname () at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.3/src/util.rs:7
#8  0x7f69e830 in tempfile::named::NamedTempFile::new_in<&std::path::PathBuf> (dir=0xbeffe034)
    at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.3/src/named.rs:120
#9  0x7f69e71c in tempfile::named::NamedTempFile::new () at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.3/src/named.rs:114
#10 0x7f6264d0 in bfc::compile_file (matches=0xbeffeae8) at src/main.rs:210
#11 0x7f6315e4 in bfc::main () at src/main.rs:276
#12 0x7f6c5d8c in sys_common::unwind::try::try_fn::h15347629866114009016 ()
#13 0x7f6c2ab0 in __rust_try ()
#14 0x7f6c58f8 in rt::lang_start::hc182d4243c0ca773kmy ()
#15 0x7f63f20c in main () at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/getopts-0.2.14/src/lib.rs:583

To make sure it wasn't just me, I've used rustc 1.7.0-dev (dedaebd5a 2016-01-12) from RustBuild this time but I'd managed to hit the bug earlier, mistaking it for problems with -flto in gcc (repeat: there's no crash with alloc_system)

@steveklabnik
Copy link
Member

Can you share the code that reproduces this?

@steveklabnik steveklabnik added I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state labels Jan 14, 2016
@MagaTailor
Copy link
Author

If you mean a test-case, no - right now all I know is bfc compiled with a standard rustc crashes.

@MagaTailor
Copy link
Author

Just a guess, however, the problem that ARM has been suffering from, could come into the equation somewhere.

Could the fix below (one of the early ones, the accepted later version is just an as *const _) be related?

Stebalien/tempfile@e7e800a

The syntax looks equivalent, just longer, but the issue itself is ARM/Android only.

@MagaTailor
Copy link
Author

Well, I've narrowed it down to the rand crate (homepage example):

Program received signal SIGSEGV, Segmentation fault.
0x7f55e530 in rand::cell::Cell<T>::get (self=0x1) at ../src/libcore/cell.rs:195
195     ../src/libcore/cell.rs: No such file or directory.
(gdb) bt
#0  0x7f55e530 in rand::cell::Cell<T>::get (self=0x1) at ../src/libcore/cell.rs:195
#1  0x7f55e508 in rand::rc::RcBoxPtr::strong<alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (self=0xb6ff84c8) at ../src/liballoc/rc.rs:875
#2  0x7f55e290 in rand::rc::RcBoxPtr::inc_strong<alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (self=0xb6ff84c8) at ../src/liballoc/rc.rs:880
#3  0x7f55e218 in rand::rc::Rc<T>.Clone::clone (self=0xb6ff84c8) at ../src/liballoc/rc.rs:491
#4  0x7f55e83c in fnfn (t=0xb6ff84c8) at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/rand-0.3.13/src/lib.rs:884
#5  0x7f55e64c in rand::thread::local::LocalKey<T>::with<closure,alloc::rc::Rc<core::cell::RefCell<rand::reseeding::ReseedingRng<rand::StdRng, rand::ThreadRngReseeder>>>> (self=0x7f5a67bc <thread_rng::THREAD_RNG_KEY::h82deed7a23a1423axgf>, f=...)
    at ../src/libstd/thread/local.rs:191
#6  0x7f55e574 in rand::thread_rng () at /home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/rand-0.3.13/src/lib.rs:884
#7  0x7f5590c0 in test_temp::main () at src/main.rs:5
#8  0x7f5719bc in sys_common::unwind::try::try_fn::h15347629866114009016 ()
#9  0x7f56efe0 in __rust_try ()
#10 0x7f571528 in rt::lang_start::hc182d4243c0ca773kmy ()
#11 0x7f559964 in main ()

alloc_system rustc still not affected. I'm rather relieved the ARM fixes were completely unrelated :)

Fascinating stuff, eh?

@MagaTailor MagaTailor changed the title Program segfaults, jemalloc worst hit [rand] Program segfaults, jemalloc worst hit Jan 15, 2016
@MagaTailor
Copy link
Author

Wonder if any compiler before #30434 or soon, after it's been reverted, might be free of this issue...

@MagaTailor
Copy link
Author

Rustc built after jemalloc downgrade doesn't produce the buggy code. Still it was an interesting example of a platform specific crash.

warricksothr added a commit to warricksothr/RustBuild that referenced this issue Feb 3, 2016
petevine pointed out an issue that causes segfaults when the code is compiled on ARM using the current compilers with jemalloc. rust-lang/rust#30919
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state
Projects
None yet
Development

No branches or pull requests

2 participants