On Thu, Apr 08, 2021 at 10:24:06AM +0200, Martin Pieuchot wrote: > firefox often crash when somebody else connects to the jitsi I'm in. > The trace looks like a stack exhaustion, see below. > > Does this ring a bell? > > #530 <signal handler called> > #531 pthread_setschedparam (thread=0x0, policy=1, param=0x2ade5ca1df0) > at /usr/src/lib/librthread/rthread_sched.c:56 > #532 0x000002ae65f9f016 in > rtc::PlatformThread::SetPriority(rtc::ThreadPriority) () from > /usr/local/lib/firefox/libxul.so.101.0 > #533 0x000002ae65f9ed75 in rtc::PlatformThread::Run() () > from /usr/local/lib/firefox/libxul.so.101.0 > #534 0x000002ae65f9ead9 in rtc::PlatformThread::StartThread(void*) () > from /usr/local/lib/firefox/libxul.so.101.0 > #535 0x000002ade9d4df51 in _rthread_start (v=<optimized out>) > at /usr/src/lib/librthread/rthread.c:96 > #536 0x000002ad9c2ec3da in __tfork_thread () > at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
This looks like, at least with our pthreads implementation, libwebrtc has a race between the newly created thread and the thread creating it. The creating thread stores the thread handle in thread_ here: https://github.com/mozilla/gecko-dev/blob/master/third_party/libwebrtc/webrtc/rtc_base/platform_thread.cc#L186 and the new thread uses it here: https://github.com/mozilla/gecko-dev/blob/master/third_party/libwebrtc/webrtc/rtc_base/platform_thread.cc#L363 which is called as almost the first thing the new thread does. Our pthread_create() only stores the pthread handle into the supplied address after __tfork_thread() returns, by which time the new thread could already be running.
