[SMT-COMP] SMT-COMP 2016: Application Track Testing

[Aaron Stump]

Hello, Mate.

On 06/11/2016 07:59 AM, Mate Soos wrote:
> Hi Aaron,
>
> First of all, thanks for getting back to me!
Sure, I am happy to discuss this matter with you.
>
> On 06/10/2016 09:11 PM, Aaron Stump wrote:
>> I am sorry you ran into a problem with stack size.  We are actually not
>> setting the stack limit explicitly in our jobscript.  What are you
>> seeing that makes you think it is lower than what is shown with "ulimit
>> -s" (namely, 8192KB)?  This value should have been something one could
>> see with the VM instance (though we are due to update that in the next
>> week or so, but I don't expect major changes).
>>
>> Certainly one could ask for a higher stack limit than 8MB, and I would
>> be happy to have us raise this or make it configurable.
> I think the stack limit was about 2MB -- and I think it might have been
> because it was set to:
>
> ulimit -s unlimited
Out of curiosity: what are you seeing that makes you think that we are 
setting "ulimit -s unlimited"?
>
> Yep -- unlimited stack is actually more limiting for whatever reason. I
> have default 8MB (Ubuntu/Debian default), RedHat Linux default has 10MB.
> Can you please create an example run with the system that ran the SMT
> Competition that simply runs
>
> ulimit -a
>
> please? That would clear things up :)
I agree that this would help clear up this issue.  Here is the output 
from a single job pair that just calls ulimit -a
(the job is 
https://www.starexec.org/starexec/secure/details/job.jsp?id=16269):

0.00/0.00	core file size          (blocks, -c) unlimited
0.00/0.00	data seg size           (kbytes, -d) unlimited
0.00/0.00	scheduling priority             (-e) 0
0.00/0.00	file size               (blocks, -f) 629145600
0.00/0.00	pending signals                 (-i) 1030922
0.00/0.00	max locked memory       (kbytes, -l) 64
0.00/0.00	max memory size         (kbytes, -m) unlimited
0.00/0.00	open files                      (-n) 1024
0.00/0.00	pipe size            (512 bytes, -p) 8
0.00/0.00	POSIX message queues     (bytes, -q) 819200
0.00/0.00	real-time priority              (-r) 0
0.00/0.00	stack size              (kbytes, -s) unlimited
0.00/0.00	cpu time               (seconds, -t) 90
0.00/0.00	max user processes              (-u) 4096
0.00/0.00	virtual memory          (kbytes, -v) 1099776
0.00/0.00	file locks                      (-x) unlimited


So indeed, the stack size is unlimited.  Our code does not seem to be setting this explicitly, so I am not sure where it is getting set.

I was not aware that ulimit -s unlimited would actually impose a default limit.  Do you mind sharing a reference for that?  This ulimit
is different from what I see when I log in to a compute node and run "ulimit -a" (there, the stack size is set to 8MB).  So it is getting
set somehow differently in the system when job pairs are getting run on the compute nodes.

This stack size limit is something we will surely want to change, though 
I would like additional confirmation that ulimit -s unlimited on linux 
will actually (and quite counterintuitively) impose this low default limit.

Cheers, and thanks for your investigation,
Aaron
>
> Thanks a lot in advance,
>
> Mate
>
>