on Linux, empty program panics if procfs is not mounted #22642

Activity

1. dwrensha

   changed the title [-]empty program panics on Linux if procfs is not mounted[/-] [+]on Linux, empty program panics if procfs is not mounted[/+] on Feb 21, 2015
2. dwrensha commented on Feb 22, 2015

   

   dwrensha

   on Feb 22, 2015

   ContributorAuthor

   More actions

   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;
   }
   
3. alexcrichton commented on Feb 23, 2015

   

   alexcrichton

   on Feb 23, 2015

   Member

   More actions

   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.
4. kentonv commented on Feb 23, 2015

   

   kentonv

   on Feb 23, 2015

   More actions

   @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?
5. alexcrichton commented on Feb 23, 2015

   

   alexcrichton

   on Feb 23, 2015

   Member

   More actions

   Perhaps yes, I'd want to have a chance to look more into it though.
6. psmit commented on Jul 15, 2015

   

   psmit

   on Jul 15, 2015

   More actions

   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?
7. dwrensha commented on Jul 16, 2015

   

   dwrensha

   on Jul 16, 2015

   ContributorAuthor

   More actions

   @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.
8. alexcrichton

   added a commit that references this issue on Jul 21, 2015

   std: Be resilient to failure in pthread_getattr_np

   ...

   This issue will close once commit d68b152 is merged into the 'incoming' branch.

   d68b152
9. bors

   added a commit that references this issue on Jul 21, 2015

   Auto merge of #27073 - alexcrichton:less-proc-fs, r=brson

   ...

   This issue will close once commit ee2d3bc is merged into the 'main' branch.

   ee2d3bc
10. bors

    closed this as completedin #27073on Jul 21, 2015