[pypy-dev] Crashes with rffi

Timothy Baldridge tbaldridge at gmail.com
Mon Nov 10 13:41:06 CET 2014


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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141110/1dc2e649/attachment.html>


More information about the pypy-dev mailing list