<div dir="ltr"><div>Hi,</div><div><br></div><div>I've been looking at ASTERISK-22079, and what might have caused it. The comment I added to the bottom of that ticket does not explain the segfault/backtrace that is attached to that ticket, so I have kept digging.</div>
<div><br></div><div>Fundamentally, I would like to know what stops a scheduled event from being cancelled while it is already running (eg. if the running event is waiting on a lock)? The problem being that both the thread that cancels the event, and the running event are both likely to call an unref().</div>
<div><br></div><div>Even worse, I believe that it is possible as a result of the above that while a thread is waiting on a lock, the data-structure it is waiting for is unref'ed to the point of being destroyed, so it ends up with a lock on a freed address.</div>
<div><br></div><div>To try and explain what I mean, -/-- represent different threads. The following is probably a worst-case scenario:<br></div><div><br></div><div>- thread1 started</div><div>-- scheduler thread started<br>
</div><div>- ao2_obj created (ref = 1)</div><div>- ast_sched_add() called with ref increment (ref = 2)</div><div>- locks ao2_obj (ref = 2, locked)</div><div>-- sched fires event - waiting on lock<br></div><div>- ast_sched_del_unref() called (ref = 1)</div>
<div>-- sched event gets lock (ref = 1, locked)</div><div>-- unrefs obj, unlocks and returns 0 to destroy sched. (ref = 0, destroyed)</div><div>- any operation on ao2_obj is now illegal.</div><div><br></div><div><div>Am I missing something obvious? Is there a defence mechanism I am not seeing?</div>
<div><br></div></div><div>Thanks,</div><div>Steve</div><div><br></div></div>