Another solution is to keep a pool of channels (i.e. never delete the oes
allocated) along with an instance count. Then a pointer+instance will tell
you if you are using the correct channel. This is messy and only works in
limited circumstances. The othe solution is to eliminate the parallel tick
generator which will iunvariably cause problems as it runs async to
everything else.

On Wed, 1 Mar 2023, David Smith wrote:

> One possibility that seems consistent (but I can't say I have a proof or even a strong indication yet) is that it's a race during the Channel destructor, e.g.:
>
> * On Channel A: ~Channel calls pTickGenerator->Invalidate(). Before destructor proceeds further:
> * The task manager thread runs Channel A's TickGenerator. The tick generator's Run() method will return 0. The task manager deletes the object (rather than requeueing it).
> * A Channel B: Creates a new TickGenerator, which happens to reuse the address that was used for Channel A's tick generator. Channel B registers the TickGenerator with the task manager.
> * On Channel A: ~Channel resumes and calls the UnregisterTask with the address of its old TickGenerator.
> * The task manager runs; and deletes Channel B's tick generator.
> * Eventually Channel B runs its ~Channel and calls Invalidate() on its tick gernerator, which has previously been deleted. The attempt to lock the structure which is supposed to be the mutex blocks.
>
> In this case a solution could be to remove the call to UnregisterTask() from the ~Channel.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1883#issuecomment-1450545646
> You are receiving this because you commented.
>
> Message ID: ***@***.***>


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1883/1450614055@github.com>

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1450614055", "url": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1450614055", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1