On Fri, 2023-09-08 at 18:26 -0400, Olivier Langlois wrote: > Any time ev_async_send() is called, there is no doubt that the > watcher > is active. > > The possible race condition is whether or not the async watcher will > be > in pending state when stopped. > > After studying libev code, I have concluded that such event is > harmless. > > It took me few hours to rediscover that most variables that libev > functions are manipulating while they look like global variables are > in > fact, loop data members that are all located in the heap. > > this makes the memory corruption explanation more plausible. > > -fsanitize=address appears to be my best tool to find my problem... > > This is beyond libev discussion.. but incidentally, this observer > class > has received a new timer watcher *this* week... > > the timer watcher is rarely started... It should be stopped > inconditionnally before the observer gets freed but if somehow it was > not, I guess that this could create similar symptoms... > > the funny thing is that if such timer watcher has been used prior the > crash, it was several hours before the crash but my traces are not > clearly showing when this watcher is started/stopped. Clearly > something > that I can improve too... > > FYI, I have found my problem.
I take great care to make sure that I stop the new timer watcher that is using the smart way #4 http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#Be_smart_about_timeouts if the timer is armed but I failed to stop it if is was timing out and this was causing an issue because it is started with ev_timer_again() and the repeat field. I guess that writing my last reply and thinking outloud made me discover what the problem was! thank you Mark for your reply and your help! Olivier _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
