Potential UAF of async frame

[kprotty]

In the listen function, It starts the async frame for client.handle in a loop and binds it to a temporary variable _. Once client.handle() suspends (e.g. from partial socket read), it will return from the async call, reiterate in the while loop, and invalidate the memory the async frame is being used with.

To handle this, would recommend dynamically allocating the frames for each client.handle and deallocate the frame one handle finished. std.event.Loop.runDetached would be a good example.

[karlseguin]

Thanks.

I initially wrote an unfinished version. At the time I was looking at other examples, and I saw that they'd add themselves to a queue for cleanup. I even wrote a gist about it based on Andrew's version that never cleaned the client up (https://gist.github.com/karlseguin/53bb8ebf945b20aa0b7472d9d30de801).

When I picked up the project again this weekend to finish it, I thought that was pretty awful so I just abandoned it all together. Of course, now we've gone from awful to just wrong.

Enough about my life story though...

Am I able to use std.event.Loop.runDetached directly to solve this? Something like:

const stream = client.NetStream{ .stream = conn.stream };
try Loop.instance.?.runDetached(allocator, client.handle, .{ H, client.NetStream, context, stream, allocator });

Fro the runDetached function comment, it seems so. But I'd be lying if I said I really understand what was going on :(