[LLVMdev] setrlimit vs ulimt

[Greg Fitzgerald]

 > 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