The plot thickens even more. I tried several other things, and was surprised to find that a call to uv_timeout works just fine, that call takes a callback, but no strings and never stores the strings internally.
On a whim I translated the entire thing (without a JIT) and everything I throw at it runs without a problem. Could this just be an issue with ffi and CPython? Timothy On Mon, Nov 10, 2014 at 1:16 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > 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 <tbaldri...@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 <ar...@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) > -- “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)
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
