on Linux, empty program panics if procfs is not mounted

[dwrensha]

The program pub main(){} fails if procfs is not mounted:

thread '<unnamed>' panicked at 'failed to get thread attributes', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/thread.rs:84

It seems that the problem is a call to pthread_getattr_np() which tries to read /proc/self/maps and fails.

$ rustc --version
rustc 1.0.0-nightly (522d09dfe 2015-02-19) (built 2015-02-21)

[dwrensha]

I found that I can work around this by defining my own entry point:

#![feature(start, std_misc)]

#[start]
fn start(argc: isize, argv: *const *const u8) -> isize {
    unsafe { ::std::rt::args::init(argc, argv); }
    // ...                                                                                            
    return 0;
}

[alexcrichton]

Hm this is somewhat worrisome. It seems overly restrictive, but on the other hand it looks like the failure in question is our detection of the stack start of the main thread in setting up the first guard page. I forget how reliable it is that linux sets up a guard page for us, and it would be tough to remove for now at least.

[kentonv]

@alexcrichton could the code skip guard page creation when /proc is unavailable (as detected by pthread_getattr_np failing)? That seems better than failing to work at all, doesn't it?

[alexcrichton]

Perhaps yes, I'd want to have a chance to look more into it though.

[psmit]

Has there been any update regarding this issue? For an AI competition we want to isolate our processes and not mounting proc inside the chroot has served well for any other languages. Is there a workaround possible in code or compilation flags?

[dwrensha]

@phsmit: You can work around the problem in code by defining your own entry point with the #[start] attribute.

Unfortunately, that's not an adequate solution in all situations, e.g. if you want to run rustc or cargo in a sandboxed environment.