Hang on destroying this from ConferenceWebTransportChannel
Opened this issue · 5 comments
When the destructor is called on the interface method that this implements from https://github.com/open-webrtc-toolkit/owt-client-native/blob/5626f534c0f5237e3a7a5303417f1eafd90f3cd2/talk/owt/sdk/conference/conferencewebtransportchannel.cc#L67 the destructor will be pended on the wait() call.
Why would the destructor need to pend on wait() if this instance will be destroyed?
Wait() makes sure its owned members are disposed before WebTransportOwtClientImpl is disposed, so it won't send new events to disposed WebTransportOwtClientImpl.
To resolve your issue, please check whether task_runner_ belongs to current thread. If so, run it on current thread instead of posting to task_runner_ to avoid deadlock.
Hi @jianjunz ,
looks like ~WebTransportOwtClientImpl isn't in fact called from io_thread_. That means, that this fix doesn't do anything. The task, that is posted in destructor doesn't seem to ever be executed by io_thread_ I cannot quite figure out why.
I think this is related, that the task contexts may be removed, so the posted cleanup call won't be called. Since the destructors are called via the automatic cleanup with shared pointer management. Destructors shouldn't post to tasks and prevent cleanup
io_thread_ is owned by WebTransportOwtClientImpl. Please destroy factory after all other QUIC objects are disposed.
To me it looks like WebTransportFactoryImpl owns io_thread_. It passes it to constructor of WebTransportOwtClientImpl, which usues it to get task_runner_.
Interesting part is that both WebTransportFactoryImpl and WebTransportOwtClientImpl are both owned by ConferenceWebTransportChannel in owt-native-client. I'm not sure which destructor is called first, but that definitely looks to me like potential race condition.