> Date: Fri, 9 Apr 2021 07:09:06 +1000
> From: Jonathan Matthew <jonat...@d14n.org>
> 
> 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.

Right.  POSIX isn't very explicit about this, but it does state that
the thread ID is stored upon successful completion.  So I don't think
portable code can rely on that until pthread_create() has returned.

Using pthread_self() in the pthread_setschedparam() call will probably
help.  But if PlatformThread::GetThreadRef() gets called early on in
the thread, there will still be a race.  Setting thread_ at the start of
PlatformThread::Run() would be better.

Reply via email to