Re: failures with "libev: ev_io_start called with corrupted watcher", ((WL)w)->next != (WL)w)
On Mon, Dec 15, 2014 at 08:28:25AM +0100, Zsbán Ambrus wrote: > On 12/15/14, Marc Lehmann wrote: > > You could try to run with a libev compiled with -DEV_FREQUENT_VERIFY=3, > > which will make very frequent (and slow) checks, in the hope of catching > > this bug earlier, but this kind of corruption is usually hard to detect > > timely for libev, as it usually happens far away from any libev call. > > Um, don't you mean -DEV_VERIFY=3 ? Yeah :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: failures with "libev: ev_io_start called with corrupted watcher", ((WL)w)->next != (WL)w)
On Sun, Dec 14, 2014 at 05:35:22PM -0800, Kirill Timofeev 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. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: failures with "libev: ev_io_start called with corrupted watcher", ((WL)w)->next != (WL)w)
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
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.
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
