[LLVMdev] setrlimit vs ulimt

[Evgeniy Stepanov]

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