Mac GL triggers failing IsOwningThreadCurrent() assertion

NEW
Unassigned

Status

()

Core
Graphics
6 years ago
6 years ago

People

(Reporter: vlad, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

I added an IsOwningThreadCurrent() assertion in MakeCurrent(), because trying to make a context current on a different thread while it's current on another one is an error.  We were doing this occasionally, and we seem to be doing it on the Mac consistently, so I commented out the assertion for now:

###!!! ASSERTION: MakeCurrent() called on different thread than this context was created on!: 'IsOwningThreadCurrent()', file ../../../gfx/gl/GLContext.h, line 603
mozilla::gl::GLContextCGL::~GLContextCGL()+0x00000019 [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x017A9789]
gfxPlatform::Shutdown()+0x00000154 [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x01731784]
nsComponentManagerImpl::KnownModule::~KnownModule()+0x0000001E [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x016A636E]
nsTArray<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayDefaultAllocator>::RemoveElementsAt(unsigned int, unsigned int)+0x00000080 [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x016A6230]
nsComponentManagerImpl::Shutdown()+0x0000017C [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x016A26AC]
mozilla::ShutdownXPCOM(nsIServiceManager*)+0x0000050B [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x01656B9B]
ScopedXPCOMStartup::~ScopedXPCOMStartup()+0x000000BB [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x0000542B]
XREMain::XRE_main(int, char**, nsXREAppData const*)+0x0000011E [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x0000CB9E]
XRE_main+0x000000D2 [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/XUL +0x0000CEF2]
main+0x000004F5 [/builds/slave/m-in-osx64-dbg/build/obj-firefox/dist/FirefoxNightlyDebug.app/Contents/MacOS/firefox-bin +0x00001D05]

This *might* be OK, as long as we know that the thread is no longer current on another thread, but that's often not the case and we were just getting a failed MakeCurrent (leading us to not free some GL resources).  If we do need to support moving a context to another thread, we need a way to explicitly remove a contxt from being current, and to update the thread that has it current (basically, we need to update both the TLS value to say what context is current on this thread *and* update mOwningThread to say what thread owns it now if MakeCurrent succeeds).
The current thread here is the main thread, right?

So that means that the GL context was created from a non-main thread?

Are you running with some experimental OMTC-on-Mac option enabled by any chance? Anyway, it'd be interesting to see a backtrace to where we created this GL context.
This was straight from the tinderbox, and the stack trace makes me think that this is definitely the main thread, so yeah, I guess we had a GLContext created elsewhere that's being destroyed on the main thread?  Maybe we use one to upload video textures via context sharing on Mac?  Maybe NS_GetCurrentThread() is returning the wrong thing on Mac during shutdown?  I dunno!
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2)
> Maybe we use
> one to upload video textures via context sharing on Mac?

Jeff would know..

> Maybe
> NS_GetCurrentThread() is returning the wrong thing on Mac during shutdown? 

If it did, we would get a million assertion failures from XPCOM, see NS_CheckThreadSafe. So, that is very unlikely.
You need to log in before you can comment on or make changes to this bug.