search

pixiv / webrtc

This is a fork of WebRTC made by pixiv Inc.
https://github.com/pixiv/webrtc/blob/branch-heads/pixiv-m78/README.pixiv.md
BSD 3-Clause "New" or "Revised" License
112 stars 35 forks source link

pthread interference #24

Open ispysoftware opened 3 years ago

ispysoftware commented 3 years ago

I've got a weird issue where if I use an ffmpeg build in my app with pthread support it causes the pixiv webrtc library to hang just after onsuccessanswer. Removing pthread support from the ffmpeg build resolves the issue - do you have any idea what could be causing this?

akihikodaki commented 3 years ago

I suppose you use .NET bindings. Probably you have altered some configuration of a thread created by .NET runtime with pthread, or ran .NET code on a thread created by pthread. It should be generally avoided to mix .NET threads and other thread implementations. The details highly depend on a specific implementation. You have to debug it thoroughly.

ispysoftware commented 3 years ago

yes on .net bindings - I haven't changed any other code - just having these ffmpeg dlls loaded in the same app domain causes it - it's like webrtc is detecting pthread support in the app domain and is creating pthreads instead of .net threads. Swapping out the ffmpeg dlls for ones built without pthread support resolves it. I can't see any pattern in the debug it seems to just hang at random places.

Also sometimes it works ok and sets up the connection successfully.

akihikodaki commented 3 years ago

The application is responsible to create a thread for .NET code, and the example code always uses System.Threading.Thread. See https://github.com/pixiv/webrtc/blob/87.0.4280.142-pixiv0/examples/unity/Assets/PeerConnection/Connection.cs#L585.

ispysoftware commented 3 years ago

yeah i know that, it's what i'm doing and it's been working fine for well over a year, it's just the new build of ffmpeg is built with pthread support which somehow is interfering with / breaking pixiv webrtc connection setup.

this is the debug output - after this the whole application hangs - but the hang happens in random places and occasionally it works ok which is making debugging it very difficult.

rtc:onsuccessanswer (physical_socket_server.cc:557): Socket::OPT_DSCP not supported. (p2p_transport_channel.cc:853): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: SetOption(5, 0) failed: 0 (message_queue.cc:518): Message took 129ms to dispatch. Posted from: PostSetSessionDescriptionSuccess@../../../../../../pc/peer_connection.cc:4392 (stun_port.cc:439): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: Starting STUN host lookup for stun.l.google.com:19305 (stun_port.cc:439): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: Starting STUN host lookup for stun1.l.google.com:19305 (stun_port.cc:439): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: Starting STUN host lookup for stun2.l.google.com:19305 (stun_port.cc:439): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: Starting STUN host lookup for stun3.l.google.com:19305 (stun_port.cc:439): Port[2095c790:0:1:0:local:Net[Hyper-V:172.28.192.1/32:Ethernet:id=4]]: Starting STUN host lookup for stun4.l.google.com:19305 (message_queue.cc:518): Message took 124ms to dispatch. Posted from: Start@../../../../../../p2p/client/basic_port_allocator.cc:1353 (basic_port_allocator.cc:1374): Net[Hyper-V:172.30.32.1/32:Ethernet:id=5]: Allocation Phase=Udp (port.cc:185): Port[1eb06750::1:0:local:Net[Hyper-V:172.30.32.1/32:Ethernet:id=5]]: Port created with network cost 0 (basic_port_allocator.cc:1445): AllocationSequence: UDPPort will be handling the STUN candidate generation. (basic_port_allocator.cc:933): Adding allocated port for 0 (basic_port_allocator.cc:954): Port[1eb06750:0:1:0:local:Net[Hyper-V:172.30.32.1/32:Ethernet:id=5]]: Added port to allocator (basic_port_allocator.cc:972): Port[1eb06750:0:1:0:local:Net[Hyper-V:172.30.32.1/32:Ethernet:id=5]]: Gathered candidate: Cand[:884439561:1:udp:2122129151:172.30.32.1:54473:local::0:YEgP:IO6NFrhctG24U/L4ab2EXlN6:5:0:0] (basic_port_allocator.cc:1000): Port[1eb06750:0:1:0:local:Net[Hyper-V:172.30.32.1/32:Ethernet:id=5]]: Port ready.

akihikodaki commented 3 years ago

Well, then I cannot help much here because it certainly requires substantial amount of debugging. If you are willing to debug it, I suggest to log platform-native thread ID to know where threads came from.