 |
 |
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 are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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