uv__has_active_reqs assertion failure from uv_work_cb

[Austin Moran]

Hello libuv,

This may be a naive question, but I'm sporadically receiving a failed assertion in uv__queue_done in unix/threadpool.c and wondered how best to approach the issue.

The problem happens in a uv_work_cb nested inside the uv_work_cb of a previous call to uv_queue_work (whew). I have a feeling I should be using uv_async_send, but I'm curious if I can use uv_ref to increment the loop's reference count to avoid the problem. 

More generally, I find myself using numerous flags and locks to maintain the order of a certain subset of events within the loop. Would a more idiomatic libuv style be to isolate these sequences into their own loops (in separate processes perhaps)?

Thanks in advance,

Austin Moran (austo)

[Ben Noordhuis]

Can you post some example code? It's not entirely clear to me what
you're trying to do. What is the assertion that you're hitting?

Some notes:

* You cannot call uv_queue_work() from inside a uv_work_cb (if that is
what you're doing), only from the thread that the event loop runs in.

* uv_ref() and uv_unref() work on individual handles, not the event
loop as a whole. For example, if you call uv_run() when your event
loop contains a single handle that is ref'd but stopped, then uv_run()
returns immediately.

[Austin Moran]

Thanks for that clarification. I've removed the nested uv_queue_work calls and no longer have the problem on Linux. On OS X, however, I still sporadically get:

Assertion failed: (uv__has_active_reqs(req->loop)), function uv__queue_done, file src/unix/threadpool.c, line 236, which seems to be a macro expansion from uv-common.h.

I'm using version 2013.06.27, Version 0.11.5 (Unstable), e3c63ff1627a14e96f54c1c62b0d68b446d8425b. Could it be that I just need to update?

Thanks,

Austin

[Ben Noordhuis]

On Tue, Aug 27, 2013 at 2:03 PM, Austin Moran <mora...@gmail.com> wrote:
> Thanks for that clarification. I've removed the nested uv_queue_work calls
> and no longer have the problem on Linux. On OS X, however, I still
> sporadically get:
> Assertion failed: (uv__has_active_reqs(req->loop)), function uv__queue_done,
> file src/unix/threadpool.c, line 236, which seems to be a macro expansion
> from uv-common.h.
> I'm using version 2013.06.27, Version 0.11.5 (Unstable),
> e3c63ff1627a14e96f54c1c62b0d68b446d8425b. Could it be that I just need to
> update?
> Thanks,
> Austin

Updating to the latest and the greatest is always a good idea though I
should note that src/unix/threadpool.c hasn't seen many changes in
recent times.

That assertion suggests that the event loop has been destroyed (or
corrupted) before all work requests have finished. uv_loop_delete()
tries to guard against that but it's not 100% foolproof. If you have
some example code, that would definitely help.

[Austin Moran]

Sorry for the delay in getting back to you on this. I wanted an example without all the noise of the original project. I also moved to version 0.11.13, which didn't change things very much.

As far as I can tell, the trouble starts in read_work, and eventually the event loop gets corrupted. It doesn't always happen after the same number of "rounds". Here's a typical example from a run on OS X.

Round 69678 finished. Incremented round to 69679

Assertion failed: (uv__has_active_reqs(stream->loop)), function uv__write_callbacks, file src/unix/stream.c, line 883.

Abort trap: 6

Hopefully it's something simple I'm missing. In any case, suggestions are greatly appreciated.

Thanks,

Austin

--
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/2ia9S7wuZX0/unsubscribe.
To unsubscribe from this group and all its topics, 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/groups/opt_out.

[Ben Noordhuis]

On Sun, Sep 8, 2013 at 5:26 AM, Austin Moran <mora...@gmail.com> wrote:
> Sorry for the delay in getting back to you on this. I wanted an example
> without all the noise of the original project. I also moved to version
> 0.11.13, which didn't change things very much.
> As far as I can tell, the trouble starts in read_work, and eventually the
> event loop gets corrupted. It doesn't always happen after the same number of
> "rounds". Here's a typical example from a run on OS X.
>
> Round 69678 finished. Incremented round to 69679
> Assertion failed: (uv__has_active_reqs(stream->loop)), function
> uv__write_callbacks, file src/unix/stream.c, line 883.
> Abort trap: 6
>
> Hopefully it's something simple I'm missing. In any case, suggestions are
> greatly appreciated.
> Thanks,
> Austin

You're calling libuv functions from inside the work callback. Don't
do that, it's unsafe. The work callback runs in another thread and
libuv is - with the exception of uv_async_send() - not thread-safe.