Reduced this down to the most basic example I can think of, the commented lines exist purely to pad out the space used on the stack which leads to the stack overflow.
#!
class " A { }
////////////////////////////////////////
////////////////////////////////////////
////////////////////////////////////////
////////////////////%%%%%%%%%%%%
This will lead to a stack overflow, as seen here with ./wren_test
[graphite@graphite bin]# ./wren_test a.wren
< several lines of errors snipped >
[./a line 7] Error at end of file: Class " A { }
////////////////////////////////////////
////////////////////////////////////////
////////////////////////////////////////
////////////////////%% already defines a method '%(_)'.
*** stack smashing detected ***: terminated
Aborted (core dumped)
Adding one more comment to pad it out past the stack check leads to a segmentation fault
#!
class " A { }
////////////////////////////////////////
////////////////////////////////////////
////////////////////////////////////////
//////////////////////%%%%%%%%%%%%
[graphite@graphite bin]# ./wren_test a.wren
< several lines of errors snipped >
[./a line 7] Error at end of file: Expect ')' after parameter name.
Segmentation fault (core dumped)
The code input is pathological but Wren should not crash on pathological inputs either.
Reduced this down to the most basic example I can think of, the commented lines exist purely to pad out the space used on the stack which leads to the stack overflow.
This will lead to a stack overflow, as seen here with
./wren_test
Adding one more comment to pad it out past the stack check leads to a segmentation fault
The code input is pathological but Wren should not crash on pathological inputs either.