So I hacked on this more over my lunch break and am still completely stumped, I've removed all deallocation in order to make sure I'm not double-freeing something (make it stop crashing then make it stop leaking is the idea). No dice.

The only thing I can figure out is that perhaps rffi is somehow freeing something I don't want it to free? Looking at the internals of rffi.llexternal, I see that it sometimes auto frees stuff, but the only things I'm passing in are raw buffers, voidp, integers, or the callback.

Since this is libuv, the library may hold onto stuff like the filename even after the call to uv_fs_open completes. The idea being it will call the callback when the operation completes, but only during a call to uv_run. So all this looks correct to me, but I get the feeling that rffi must be doing some magic somewhere that I don't want.

Any input would be awesome, I've been hacking on this for about half a week now and I'm completely stumped.

Timothy

On Mon, Nov 10, 2014 at 7:55 AM, Timothy Baldridge <tbaldridge@gmail.com> wrote:

That could be true for uv_fs_read, but in the minimal test case (in my last email) I'm only opening a file 10 times, after the first few iterations of opening the file (2-3 times) that test crashes.

Timothy

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

We're talking past each other. I think that I already found that your
code is not correct according to the docs. You need to fix the
signature of uv_fs_read() and create an array 'uv_buf_t[]', possibly
of length 1. I may be wrong though.

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)

“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)