Merge pull request #68 from jow-/vm-callframe-double-free-fix

2 files changed, 39 insertions, 3 deletions

diff --git a/tests/cram/test_basic.t b/tests/cram/test_basic.t
index b85167f..7308002 100644
--- a/tests/cram/test_basic.t
+++ b/tests/cram/test_basic.t
@@ -79,19 +79,19 @@ check that ucode prints greetings:
 
 check that ucode provides proper error messages:
 
-  $ ucode -l foo
+  $ touch lib.uc; ucode -l lib
   Require either -e expression or source file
   [1]
 
   $ ucode -l foo -e ' '
   Runtime error: No module named 'foo' could be found
   
-  [254]
+  [1]
 
   $ touch moo; ucode -l foo moo
   Runtime error: No module named 'foo' could be found
   
-  [254]
+  [1]
 
 check that ucode can load fs module:
 
diff --git a/tests/custom/04_bugs/35_vm_callframe_double_free b/tests/custom/04_bugs/35_vm_callframe_double_free
new file mode 100644
index 0000000..bb816eb
--- /dev/null
+++ b/tests/custom/04_bugs/35_vm_callframe_double_free
@@ -0,0 +1,36 @@
+When invoking a native function as toplevel VM call which indirectly
+triggers an unhandled exception in managed code, the callframes are
+completely reset before the C function returns, leading to invalid
+memory accesses when `uc_vm_call_native()` subsequently popped it's
+own callframe again.
+
+This issue did not surface by executing script code through the
+interpreter since in this case the VM will always execute a managed
+code as toplevel call, but it could be triggered by invoking a native
+function triggering an exception through the C API using `uc_vm_call()`
+on a fresh `uc_vm_t` context or by utilizing the CLI interpreters `-l`
+flag to preload a native code library triggering an exception.
+
+
+-- File ex.uc --
+die("Exception");
+-- End --
+
+-- Args --
+-L files/ -l ex
+-- End --
+
+-- Expect stderr --
+Exception
+In main(), file files/ex.uc, line 1, byte 16:
+  called from anonymous function ([C])
+
+ `die("Exception");`
+  Near here -----^
+
+
+-- End --
+
+-- Testcase --
+not reached
+-- End --