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