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/te... " https://github.com/pixie-lang/pixie/blob/async-io-file/pixie/vm/libs/test/te... " 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)