Another race in db_close_events()

[mdavidsaver]

Mark Rivers reports a valgrind alert in db_close_events().

https://epics.anl.gov/core-talk/2021/msg00665.php

This looks like a race leading to a real use-after-free which is
being "covered up" by the free list.

>>> ==146728== Thread 25 CAS-client:
>>> ==146728== Invalid read of size 8
>>> ==146728== at 0xE37113: db_close_events (dbEvent.c:378)

In dbEvent.c db_close_events()

> /* notify the waiting task */
> epicsEventSignal(evUser->ppendsem);
>
> if(evUser->taskid) // <- line 378
> epicsThreadMustJoin(evUser->taskid);
> /* evUser has been deleted by the worker */

Since event_task() is deleting evUser, it looks like everything from the epicsEventSignal()
onwards is a race. event_task() also deletes ppendsem, which could happen before
epicsEventSignal() returns. So I don't think it would be enough to save 'evUser->taskid'
before signaling.

I'm developing a long history with this particular issue. This being the second time I've introduced a similar regression (cf. lp:1730982). This time with 37a76b433a9e7d5a8d26a13fd21ad62f20a0c1c1 (in 7.0.3.1).

[mdavidsaver (mdavidsaver)]

cf. https://github.com/epics-base/epics-base/pull/151