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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Message ID: <xrootd/xrootd/issues/1883/1450545646@github.com>
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1450545646",
"url": "https://github.com/xrootd/xrootd/issues/1883#issuecomment-1450545646",
"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
