Lifecycle management of uv_work_t?

[William Ehlhardt]

Hi folks,

In the attached file, I delete a uv_work_t after running uv_queue_work, which causes a use-after-free crash. This is somewhat surprising behavior.

1. The documentation does not make it clear that the uv_work_t passed to uv_queue_work needs to remain alive until (presumably?) the callbacks have all completed, which leads to:

2. Since uv_queue_work spins off another thread to do the work, and since this may happen in a context where you're spinning many uv_work_t tasks off to run simultaneously, it's not clear where the uv_work_t should be deleted. Declaring it on the stack of the caller of uv_run isn't a very good solution because you can't stack-declare arbitrary numbers of uv_work_t, which you need to do if you're potentially queuing lots of background work at once. Allocating it on the heap, meanwhile, brings up the question of (A) is user code responsible for deleting the uv_work_t, or is libuv? and (B) if user code is responsible, when is it safe to delete the work_t? During the "done" callback?

-William

[William Ehlhardt]

Sorry; attached is the same file with less wacky indentation.

[William Ehlhardt]

I thought about this some more. Obviously in (2), user code has to be responsible for deletion, since uv_queue_work takes a pointer that could be to a stack-allocated uv_work_t. So the question remains: when is it safe to delete the uv_work_t?

On Wednesday, December 17, 2014 8:31:20 PM UTC-6, William Ehlhardt wrote:

[Fedor Indutny]

William,

Libuv does not allocate or destroy anything, except `uv_loop_new` function (which is going to be removed one day).

Every request, be it write/shutdown/queue_work is allocated by user and must be kept alive.

Cheers,

Fedor.

--
You received this message because you are subscribed to the Google Groups "libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libuv+un...@googlegroups.com.
To post to this group, send email to li...@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

[William Ehlhardt]

On Wed, Dec 17, 2014 at 9:28 PM, Fedor Indutny <fe...@indutny.com> wrote:

Every request, be it write/shutdown/queue_work is allocated by user and must be kept alive.

Right. So when is it safe to delete the uv_work_t? It would be most convenient to be able to free() it during the "after" callback in my queue.c. Is it safe to do that?

If not, how should I manage the pending uv_work_t objects? Should I keep a list of them somewhere and mark them as "done" in the "after" callback, then have some other means of cleaning them up later?

 

Cheers,

Fedor.

On Thu, Dec 18, 2014 at 9:38 AM, William Ehlhardt <william...@gmail.com> wrote:

I thought about this some more. Obviously in (2), user code has to be responsible for deletion, since uv_queue_work takes a pointer that could be to a stack-allocated uv_work_t. So the question remains: when is it safe to delete the uv_work_t?

On Wednesday, December 17, 2014 8:31:20 PM UTC-6, William Ehlhardt wrote:

Hi folks,

In the attached file, I delete a uv_work_t after running uv_queue_work, which causes a use-after-free crash. This is somewhat surprising behavior.

1. The documentation does not make it clear that the uv_work_t passed to uv_queue_work needs to remain alive until (presumably?) the callbacks have all completed, which leads to:

2. Since uv_queue_work spins off another thread to do the work, and since this may happen in a context where you're spinning many uv_work_t tasks off to run simultaneously, it's not clear where the uv_work_t should be deleted. Declaring it on the stack of the caller of uv_run isn't a very good solution because you can't stack-declare arbitrary numbers of uv_work_t, which you need to do if you're potentially queuing lots of background work at once. Allocating it on the heap, meanwhile, brings up the question of (A) is user code responsible for deleting the uv_work_t, or is libuv? and (B) if user code is responsible, when is it safe to delete the work_t? During the "done" callback?

-William

--
You received this message because you are subscribed to the Google Groups "libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libuv+un...@googlegroups.com.
To post to this group, send email to li...@googlegroups.com.
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "libuv" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libuv/MBl46Ofe2Is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libuv+un...@googlegroups.com.

[Fedor Indutny]

Yes, it is safe to delete it in after callback. Generally the rule of thumb here is that the struct could be deleted after it is not used or was closed.