[LLVMdev] setrlimit vs ulimt

[Greg Fitzgerald]

>>     %run sh -c "ulimit -s 8192 && %t"
> This would not work

I 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 can
not 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