> Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not?Because the llvm-symbolizer the runtime finds is built for the host architecture. This is weird, yes, but once we integrate the symbolizer, it goes away.> Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary > %run %ulimit -s 8192 %t?I like that idea. How do you feel about this short-term solution: %run sh -c "ulimit -s 8192 && %t" -Greg On Thu, May 29, 2014 at 12:05 PM, Evgeniy Stepanov <eugenis at google.com> wrote:> On Thu, May 29, 2014 at 10:44 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>> execv(argv[0]) is a canonical way to restart the >>> process, it's sad that the emulator interferes with that. >> >> We have the option to emulate the instruction set or emulate the OS. >> The former is lighter weight and easy to configure. The downside is >> that system calls route to the host system. That can be useful if, >> for example, the executable invokes llvm-symbolizer. >> >> While execv(argv[0]) may be the right way to restart, this process >> doesn't need to be restarted. It needs to be configured before the >> first invocation. > > I must be missing something here. Why does fork-exec for > llvm-symbolizer work, but simple exec(self) does not? > Is it because argv[0] is not what it normally is? Can it be worked around? > >> >> >>> Propagating ulimit setting in %run wrapper sounds wrong. >> >> In my opinion, propagating ulimit settings in the wrapper is >> consistent with whitelisting environment variables. > > Target platform may be quite different from host and simply > replicating the entire "ulimit -a" would be wrong. Ideally, we need to > propagate only those limits that were set explicitly in the test. > Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary, like %run %ulimit -s 8192 %t? > > >> >> -Greg >> >> On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote: >>> execv(argv[0]) is a canonical way to restart the process, it's sad >>> that the emulator interferes with that. >>> >>> ulimit does not work for me because it needs to run on the device, in >>> the same shell as the test binary. >>> Propagating ulimit setting in %run wrapper sounds wrong. >>> >>> >>> On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>> Hi Evgeniy, >>>> >>>> This fix causes me trouble in the emulator because of the execv(argv[0]): >>>> >>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >>>> >>>> Instead using setrlimit from within the C++ code, can you set the >>>> stack limit using ulimit on the RUN lines? Also, should this test be >>>> moved to the Posix or Linux directory? >>>> >>>> Thanks, >>>> Greg
On Fri, May 30, 2014 at 1:07 AM, Greg Fitzgerald <garious at gmail.com> wrote:> > Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? > > Because the llvm-symbolizer the runtime finds is built for the host > architecture. This is weird, yes, but once we integrate the > symbolizer, it goes away. > > >> Could we write a ulimit-like utility that would do setrlimit and then >> exec the specified binary >> %run %ulimit -s 8192 %t? > > I like that idea. How do you feel about this short-term solution: > > %run sh -c "ulimit -s 8192 && %t"This would not work, because for now %run is empty, and %t is a wrapper. Even if I move the logic to %run, it would need to map %t (which is an absolute path on the host) to the device path somehow. Btw, for some reason %run is defined in the top-level lit.cfg, and can not be redefined for individual configurations. I guess that's because you are using the standalone build? Perhaps we should all switch to that soon.> > -Greg > > On Thu, May 29, 2014 at 12:05 PM, Evgeniy Stepanov <eugenis at google.com> wrote: >> On Thu, May 29, 2014 at 10:44 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>> execv(argv[0]) is a canonical way to restart the >>>> process, it's sad that the emulator interferes with that. >>> >>> We have the option to emulate the instruction set or emulate the OS. >>> The former is lighter weight and easy to configure. The downside is >>> that system calls route to the host system. That can be useful if, >>> for example, the executable invokes llvm-symbolizer. >>> >>> While execv(argv[0]) may be the right way to restart, this process >>> doesn't need to be restarted. It needs to be configured before the >>> first invocation. >> >> I must be missing something here. Why does fork-exec for >> llvm-symbolizer work, but simple exec(self) does not? >> Is it because argv[0] is not what it normally is? Can it be worked around? >> >>> >>> >>>> Propagating ulimit setting in %run wrapper sounds wrong. >>> >>> In my opinion, propagating ulimit settings in the wrapper is >>> consistent with whitelisting environment variables. >> >> Target platform may be quite different from host and simply >> replicating the entire "ulimit -a" would be wrong. Ideally, we need to >> propagate only those limits that were set explicitly in the test. >> Could we write a ulimit-like utility that would do setrlimit and then >> exec the specified binary, like %run %ulimit -s 8192 %t? >> >> >>> >>> -Greg >>> >>> On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote: >>>> execv(argv[0]) is a canonical way to restart the process, it's sad >>>> that the emulator interferes with that. >>>> >>>> ulimit does not work for me because it needs to run on the device, in >>>> the same shell as the test binary. >>>> Propagating ulimit setting in %run wrapper sounds wrong. >>>> >>>> >>>> On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>>> Hi Evgeniy, >>>>> >>>>> This fix causes me trouble in the emulator because of the execv(argv[0]): >>>>> >>>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >>>>> >>>>> Instead using setrlimit from within the C++ code, can you set the >>>>> stack limit using ulimit on the RUN lines? Also, should this test be >>>>> moved to the Posix or Linux directory? >>>>> >>>>> Thanks, >>>>> Greg
>> %run sh -c "ulimit -s 8192 && %t" > This would not workI agree. I think your idea of a target-compiled 'ulimit' is the best plan.> Btw, for some reason %run is defined in the top-level lit.cfg, and cannot be redefined for individual configurations. Instead of overriding %run, set 'config.emulator'.> I guess that's because you are using the standalone > build? Perhaps we should all switch to that soon.The standalone build is really quite nice. On my Linux box, Config+Build time for ARM build (ASan+UBSan): 35s. x86_64+i386 of all sanitizers 45s. I just took a shot at building it for Android. Choked in try_compile: android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ --sysroot=android-ndk-r9/platforms/android-18/arch-arm -Bandroid-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64 -o simple.cc.o -c simple.cc simple.cc:2:18: fatal error: limits: No such file or directory #include <limits> I see limits.h in the sysroot. How do I help the NDK gcc find it? I'm trying to avoid making the standalone toolchain. Is that dumb? Thanks, Greg On Fri, May 30, 2014 at 1:38 AM, Evgeniy Stepanov <eugenis at google.com> wrote:> On Fri, May 30, 2014 at 1:07 AM, Greg Fitzgerald <garious at gmail.com> wrote: >> > Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? >> >> Because the llvm-symbolizer the runtime finds is built for the host >> architecture. This is weird, yes, but once we integrate the >> symbolizer, it goes away. >> >> >>> Could we write a ulimit-like utility that would do setrlimit and then >>> exec the specified binary >>> %run %ulimit -s 8192 %t? >> >> I like that idea. How do you feel about this short-term solution: >> >> %run sh -c "ulimit -s 8192 && %t" > > This would not work, because for now %run is empty, and %t is a > wrapper. Even if I move the logic to %run, it would need to map %t > (which is an absolute path on the host) to the device path somehow. > > Btw, for some reason %run is defined in the top-level lit.cfg, and can > not be redefined for individual configurations. I guess that's because > you are using the standalone build? Perhaps we should all switch to > that soon. > >> >> -Greg >> >> On Thu, May 29, 2014 at 12:05 PM, Evgeniy Stepanov <eugenis at google.com> wrote: >>> On Thu, May 29, 2014 at 10:44 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>>> execv(argv[0]) is a canonical way to restart the >>>>> process, it's sad that the emulator interferes with that. >>>> >>>> We have the option to emulate the instruction set or emulate the OS. >>>> The former is lighter weight and easy to configure. The downside is >>>> that system calls route to the host system. That can be useful if, >>>> for example, the executable invokes llvm-symbolizer. >>>> >>>> While execv(argv[0]) may be the right way to restart, this process >>>> doesn't need to be restarted. It needs to be configured before the >>>> first invocation. >>> >>> I must be missing something here. Why does fork-exec for >>> llvm-symbolizer work, but simple exec(self) does not? >>> Is it because argv[0] is not what it normally is? Can it be worked around? >>> >>>> >>>> >>>>> Propagating ulimit setting in %run wrapper sounds wrong. >>>> >>>> In my opinion, propagating ulimit settings in the wrapper is >>>> consistent with whitelisting environment variables. >>> >>> Target platform may be quite different from host and simply >>> replicating the entire "ulimit -a" would be wrong. Ideally, we need to >>> propagate only those limits that were set explicitly in the test. >>> Could we write a ulimit-like utility that would do setrlimit and then >>> exec the specified binary, like %run %ulimit -s 8192 %t? >>> >>> >>>> >>>> -Greg >>>> >>>> On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote: >>>>> execv(argv[0]) is a canonical way to restart the process, it's sad >>>>> that the emulator interferes with that. >>>>> >>>>> ulimit does not work for me because it needs to run on the device, in >>>>> the same shell as the test binary. >>>>> Propagating ulimit setting in %run wrapper sounds wrong. >>>>> >>>>> >>>>> On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>>>> Hi Evgeniy, >>>>>> >>>>>> This fix causes me trouble in the emulator because of the execv(argv[0]): >>>>>> >>>>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >>>>>> >>>>>> Instead using setrlimit from within the C++ code, can you set the >>>>>> stack limit using ulimit on the RUN lines? Also, should this test be >>>>>> moved to the Posix or Linux directory? >>>>>> >>>>>> Thanks, >>>>>> Greg