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

[Armin Biere]

Oops script got truncated:

#!/bin/sh
set -x
cat << EOF > /tmp/stack-overflow.c
#include <stdio.h>
#include <pthread.h>
pthread_t thread;
void f (int i) { printf ("%d\n", i); fflush (stdout); f (i+1); }
void * run (void * dummy) { f (0); }
int main () { pthread_create (&thread, 0, run, 0); pthread_join (thread,
0); }
EOF
ulimit -s
gcc -o /tmp/stack-overflow /tmp/stack-overflow.c -pthread
time -f %E /tmp/stack-overflow|tail -1
ulimit -s unlimited
ulimit -s
time -f %E /tmp/stack-overflow|tail -1


This should now be complete ...

Armin

On Mon, Jun 13, 2016 at 8:18 AM, Armin Biere <armin.biere at gmail.com> wrote:

> Yep, now with pthreads (ubuntu 16.04):
>
> $ ./test-ulimit-unlimited.sh
> + cat
> + ulimit -s
> 8192
> + gcc -o /tmp/stack-overflow /tmp/stack-overflow.c -pthread
> + time -f %E /tmp/stack-overflow
> + tail -1
> Command terminated by signal 11
> 0:00.45
> 261955
> + ulimit -s unlimited
> + ulimit -s
> unlimited
> + time -f %E /tmp/stack-overflow
> + tail -1
> Command terminated by signal 11
> 0:00.17
> 65347
>
>
>
> And here is the modified script for testing:
>
> #include <stdio.h>
> #include <pthread.h>
> pthread_t thread;
> void f (int i) { printf ("%d\n", i); fflush (stdout); f (i+1); }
> void * run (void * dummy) { f (0); }
> int main () { pthread_create (&thread, 0, run, 0); pthread_join (thread,
> 0); }
> EOF
> ulimit -s
> gcc -o /tmp/stack-overflow /tmp/stack-overflow.c -pthread
> time -f %E /tmp/stack-overflow|tail -1
> ulimit -s unlimited
> ulimit -s
> time -f %E /tmp/stack-overflow|tail -1
>
>
>
> On Mon, Jun 13, 2016 at 2:05 AM, Mate Soos <soos.mate at gmail.com> wrote:
>
>> Hi Clark,
>>
>> On 06/12/2016 06:06 PM, Clark Barrett wrote:
>> > Hi all - I believe we had this exact problem in the 2014 competition.
>> > The default stack size for a thread is 2 mb unless you explicitly set it
>> > to be more.  We fixed it by using the boost threading library and
>> > explicitly setting the stack size.  For the competition, we asked David
>> > Cok to rerun our patched executable as a noncompetitive entry (i.e. just
>> > for comparison purposes) which he did.  Perhaps a similar compromise
>> > would be appropriate here.  Sorry you guys got bit by this - I know how
>> > frustrating that is.
>>
>> Thanks! Yep, a bit of a pain, though I look a this more as a way to
>> learn, which I (hopefully) seem to do. Next time we'll make sure to ask
>> ulimit to be set to a fixed value (like 8M) rather than "unlimited"
>> which seems pretty limiting, actually :) To be honest, I'm not sure it
>> would have made such a difference to the end results. I still need to
>> work harder on some of the multi-threaded stuff.
>>
>> Thanks for the kind email :)
>>
>> Mate
>>
>>
>>
>