failures with "libev: ev_io_start called with corrupted watcher", ((WL)w)->next != (WL)w)

[Kirill Timofeev]

Hi Marc,

thanks for guidelines, but I'm confused. I looked at code examples and 
currently I do as follows:

create connection
while connection alive {
ev_io_init()
ev_io_start()
ev_io_stop()
}

This works for both udp and tcp connections with very rare Assert 
failures on tcp connections. Am I using library wrong?

Another question. Your sequence is: ev_xxx_stop/ev_xxx_set/ev_xxx_start. 
Does this mean that ev_xx_init() implicitly invokes start() logic?

Thanks,
Kirill.

On 12/17/2014 04:16 AM, Marc Lehmann wrote:
> On Sun, Dec 14, 2014 at 05:35:22PM -0800, Kirill Timofeev <kirill.timofeev at hulu.com> wrote:
>> checked once again code and don't see where I could miss using
>> ev_io_stop(). I would really appreciate if you would have a look at
> Another common option is to call ev_init on active watcher memory, which
> also corrupts it.
>
>> unclear). Also please let me know if adding some logging can help.
> Well, -DEV_VERIFY=3 would be a good first step, as that might catch the bug
> earlier.
>
> Anyways, I am not going to debug this for you, but questions you have to ask
> yourself are things like "what keeps ds_schedule_flush from calling
> ev_io_init on flush_watcher twice (without intervening stop)?".
>
> In general, it's often easier to structure your program like this:
>
> on job creation (e.g. connection):
> - allocate watcher memory
> - ev_xx_init them all
>
> in between:
> - call ev_xxx_stop/ev_xxx_set/ev_xxx_start as you wish, in that order
>
> on job end/cancellatiopn etc:
> - call ev_xxx_stop on all watchers
> - free memory
>
> This almost ensures that you get it right.
>