So I think I've narrowed it down a bit to this: it seems to only happen when I can one of these libuv functions for the second time. The second test in this file throws the exception: https://github.com/pixie-lang/pixie/blob/async-io-file/pixie/vm/libs/test/test_uv_file.py#L20

"https://github.com/pixie-lang/pixie/blob/async-io-file/pixie/vm/libs/test/test_uv_file.py#L20"

All I'm doing here is opening a file (and never closing it, but that shouldn't be a problem). The code in FSOpen is even cleaning up the buffers I allocate this time. 

A bit of background on the process, FSOpen is a UVFunction. The function execute_uv_func, creates a continuation from the current stacklet and then calls .execute_uv passing it the uv loop and the continuation (k). Once libuv calls the callback fs_cb, the continuation is put into a list of pending stacklets and the loop inside with_stacklets will continue its execution at some time in the future.

The only libuv functions called by this code is uv_fs_open, uv_fs_cleanup, and uv_run. 

The first test runs fine, but the second causes the crash. 

Timothy

On Mon, Nov 10, 2014 at 12:38 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Timothy,

>From the docs, the signature of uv_fs_read() is this
(http://docs.libuv.org/en/latest/fs.html#c.uv_fs_read):

int uv_fs_read(uv_loop_t* loop, uv_fs_t* req, uv_file file, const
uv_buf_t bufs[], unsigned int nbufs, int64_t offset, uv_fs_cb cb)

This seems to differ from what you're reporting.  The "bufs" and
"nbufs" are not a pointer and size of a resulting buffer, but instead
they are an array of buffers (possibly more than one), and the length
of this array (i.e. the number of buffers).  Each buffer is described
by a uv_buf_t.  This is more like preadv(2) than read(2).


A bientôt,

Armin.



--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)