[Affected versions]: - Firefox 50.0b5 [Affected platforms]: - Mac OS X 10.11.6, Mac OS X 10.12 [Steps to reproduce]: 1. Open Firefox in 32-bit mode. 2. Go to a website that contains videos (e.g. youtube.com) and play a video. [Expected result]: - The video is correctly played. [Actual result]: - The video is not played. [Regression range]: - Last good: 50.0a1 (2016-07-30) - First bad: Firefox 50.0a1 (2016-07-31) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2ea3d51ba1bb9f5c3b6921c43ea63f70b4fdf5d2&tochange=e5859dfe0bcbd40f4e33f4a633f73ea3473a7849 [Additional notes]: - The videos are working correctly on the 64-bit builds.

Do you get the same problem simply opening a local MP4 video?

I've downloaded a MP4 video on my local machine and tried to play it with Firefox opened in 32-bit mode. The video is not played. It's the same behavior as in the Actual Result from Comment 0.

Tracked for 50+ as this is a pretty common scenario.

Hi Mihai, could you please find a regression window promptly? I'd like to know what made this regress.

(In reply to Ritu Kothari (:ritu) from comment #4) > Hi Mihai, could you please find a regression window promptly? I'd like to > know what made this regress. How common could this be? It is an OS 10.9 requirement that the processor be 64 bits capable. I wonder why we still ship a universal binary actually since we drop 10.6 to 10.8 support. It's an interesting bug nonetheless, I can't see anything in the regression window that would have an impact video decoding...

(In reply to Ritu Kothari (:ritu) from comment #4) > Hi Mihai, could you please find a regression window promptly? I'd like to > know what made this regress. Hi Ritu, I managed to find a regression range manually and this is the best I could do: - Last good: 50.0a1 (2016-07-30) - First bad: Firefox 50.0a1 (2016-07-31) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2ea3d51ba1bb9f5c3b6921c43ea63f70b4fdf5d2&tochange=e5859dfe0bcbd40f4e33f4a633f73ea3473a7849 I'm not quite sure what caused this issue. Please let me know if there is any other information needed.

Not a lot of relevant-looking changes in that range. Maybe bug 1290036 or bug 1289525?

(In reply to Ritu Kothari (:ritu) from comment #3) > Tracked for 50+ as this is a pretty common scenario. 32-bit mode, specifically, on OS X is fairly uncommon AFAIK. I think it should only be hit now by users with 32-bit NPAPI plugins that cause us to revert to 32-bit mode? Since we still support this (I think?) we should probably fix it, but I'd assume it's not a large number of users.

bsmedberg told me that we're dropping support for 32 bit MacOS in 52, that is, at the time when we drop NPAPI plugin support. Is that not the case?

Ted, someone said you may have hourly builds ... do you have 32-bit hourly MacOS builds that could help track down a tighter regression range?

I don't know who thinks that, but no, I do not. I don't think we should spend any time on this--we dropped support for non-64-bit versions of OS X. We haven't stopped shipping universal binaries because they're necessary for users to run 32-bit plugins (read: Silverlight), but that doesn't mean the browser runs in 32-bit, just the plugin-container. We're planning to drop support for Universal builds in the Firefox 53 release cycle, AFAIK: bug 1295375.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #11) > I don't know who thinks that, but no, I do not. I don't think we should > spend any time on this--we dropped support for non-64-bit versions of OS X. > We haven't stopped shipping universal binaries because they're necessary for > users to run 32-bit plugins (read: Silverlight), but that doesn't mean the > browser runs in 32-bit, just the plugin-container. We're planning to drop > support for Universal builds in the Firefox 53 release cycle, AFAIK: bug > 1295375. 53 cycle is still ~18 weeks away from go-live. In the mean time, I would consider Firefox as a supported browser in 32-bit OSX versions and therefore support a very basic scenario like video playback. We should be taking a stance of "let's not do this when we are close enough" and given that 49 is on release channel, we are not that close to 53.

But note "Snow Leopard is the last release of Mac OS X to support the 32-bit Intel Core Solo and Intel Core Duo CPUs." from https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard . We dropped support for 10.6 recently: https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/ so we don't support any versions of OS X that can't run Firefox in 64-bit mode. Users can still run Firefox in 32-bit mode (by jumping through hoops), but I think we should consider that an unsupported configuration. You have to right click on the application, "Get Info", then check "Open in 32-bit mode".

interestingly, when I attempt to play a file with FF opened in 32 bits mode, it always decode the first frame properly and then stall.

narrower mozregression: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=674c51af1dcc31a139b792ebef9ebcd509f87ed3&tochange=4dcce7c669037971a862a39d3a44790523d9c819 my gutfeel is on cubeb update. Note that if you attempt to play any videos when running in 32 bits mode, then you can no longer exit firefox cleanly. it will hang

confirmed: 658d4501eae0c1224ed6a68d7563fbe7e7193e92 is the first bad commit commit 658d4501eae0c1224ed6a68d7563fbe7e7193e92 Author: Alex Chronopoulos <achronop@gmail.com> Date: Fri Jul 29 13:40:52 2016 +0200 Bug 1290425 - Update cubeb to revision 6278ef2f73. r=padenot :040000 040000 c3cf6b896497f6ba18794ecaf5ec62ac52f839e3 d0b80259f4c2be2f899e005e93c1c517359aaba9 M media

It's a deadlock in audiounit_output_callback, I don't see how this would be limited to 32 bits app. (lldb) bt * thread #73: tid = 0x149e62, 0x9f68934a libsystem_kernel.dylib`__psynch_mutexwait + 10, name = 'com.apple.audio.IOThread.client' frame #0: 0x9f68934a libsystem_kernel.dylib`__psynch_mutexwait + 10 frame #1: 0x9f76a5c5 libsystem_pthread.dylib`_pthread_mutex_lock_wait + 86 frame #2: 0x9f767d86 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 302 frame #3: 0x9f767c39 libsystem_pthread.dylib`pthread_mutex_lock + 127 frame #4: 0x075c0c72 XUL`owned_critical_section::enter(this=0x8183d8a4) + 34 at cubeb_utils_unix.h:56 frame #5: 0x075c0c45 XUL`auto_lock::auto_lock(this=0xb3739608, lock=0x8183d8a4) + 37 at cubeb_utils.h:201 frame #6: 0x075be564 XUL`auto_lock::auto_lock(this=0xb3739608, lock=0x8183d8a4) + 36 at cubeb_utils.h:200 * frame #7: 0x075c3701 XUL`audiounit_output_callback(user_ptr=0x8183d830, flags=0xb3739708, tstamp=0xb37396c8, bus=0, output_frames=471, outBufferList=0x80f578a0) + 289 at cubeb_audiounit.cpp:350 frame #8: 0x6c645a76 CoreAudio`AUInputElement::PullInput(unsigned long&, AudioTimeStamp const&, unsigned long, unsigned long) + 172 frame #9: 0x6c522f3e CoreAudio`AUInputFormatConverter2::InputProc(OpaqueAudioConverter*, unsigned long*, AudioBufferList*, AudioStreamPacketDescription**, void*) + 266 frame #10: 0x93762167 AudioToolbox`AudioConverterChain::CallInputProc(unsigned long) + 377 frame #11: 0x93761f66 AudioToolbox`AudioConverterChain::FillBufferFromInputProc(unsigned long*, CABufferList*) + 382 frame #12: 0x9373feff AudioToolbox`BufferedAudioConverter::GetInputBytes(unsigned long, unsigned long&, CABufferList const*&) + 173 frame #13: 0x9376e5b5 AudioToolbox`Resampler2Wrapper::RenderOutput(CABufferList*, unsigned long, unsigned long&) + 145 frame #14: 0x9371c35a AudioToolbox`SampleRateConverter::RenderOutput(CABufferList*, unsigned long, unsigned long&, AudioStreamPacketDescription*) + 30 frame #15: 0x9373fd88 AudioToolbox`BufferedAudioConverter::FillBuffer(unsigned long&, AudioBufferList&, AudioStreamPacketDescription*) + 262 frame #16: 0x93761ca3 AudioToolbox`AudioConverterChain::RenderOutput(CABufferList*, unsigned long, unsigned long&, AudioStreamPacketDescription*) + 101 frame #17: 0x9373fd88 AudioToolbox`BufferedAudioConverter::FillBuffer(unsigned long&, AudioBufferList&, AudioStreamPacketDescription*) + 262 frame #18: 0x93709f53 AudioToolbox`AudioConverterFillComplexBuffer + 313 frame #19: 0x6c5227bf CoreAudio`AUInputFormatConverter2::PullAndConvertInput(AudioTimeStamp const&, unsigned long&, AudioBufferList&, AudioStreamPacketDescription*, bool&) + 139 frame #20: 0x6c5225ea CoreAudio`AUConverterBase::RenderBus(unsigned long&, AudioTimeStamp const&, unsigned long, unsigned long) + 562 frame #21: 0x6c648b65 CoreAudio`AUBase::DoRenderBus(unsigned long&, AudioTimeStamp const&, unsigned long, AUOutputElement*, unsigned long, AudioBufferList&) + 141 frame #22: 0x6c64889c CoreAudio`AUBase::DoRender(unsigned long&, AudioTimeStamp const&, unsigned long, unsigned long, AudioBufferList&) + 552 frame #23: 0x6c525dd3 CoreAudio`AUHAL::AUIOProc(unsigned long, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 2553 frame #24: 0x9415c6b2 CoreAudio`HALC_ProxyIOContext::IOWorkLoop() + 7980 frame #25: 0x9415a514 CoreAudio`HALC_ProxyIOContext::IOThreadEntry(void*) + 236 frame #26: 0x9418c643 CoreAudio`___ZN19HALC_ProxyIOContextC2Emj_block_invoke + 20 frame #27: 0x9415a3df CoreAudio`HALB_IOThread::Entry(void*) + 71 frame #28: 0x9f76a11b libsystem_pthread.dylib`_pthread_body + 184 frame #29: 0x9f76a063 libsystem_pthread.dylib`_pthread_start + 243 frame #30: 0x9f76993e libsystem_pthread.dylib`thread_start + 34 The other thread with the lock: (lldb) bt * thread #71: tid = 0x149e4d, 0x9f68934a libsystem_kernel.dylib`__psynch_mutexwait + 10, name = 'MediaPl~back #1' frame #0: 0x9f68934a libsystem_kernel.dylib`__psynch_mutexwait + 10 frame #1: 0x9f76a5c5 libsystem_pthread.dylib`_pthread_mutex_lock_wait + 86 frame #2: 0x9f767d86 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 302 frame #3: 0x9f767c39 libsystem_pthread.dylib`pthread_mutex_lock + 127 frame #4: 0x075c0c72 XUL`owned_critical_section::enter(this=0x8183d8a4) + 34 at cubeb_utils_unix.h:56 frame #5: 0x075c0c45 XUL`auto_lock::auto_lock(this=0xb34ab2e8, lock=0x8183d8a4) + 37 at cubeb_utils.h:201 frame #6: 0x075be564 XUL`auto_lock::auto_lock(this=0xb34ab2e8, lock=0x8183d8a4) + 36 at cubeb_utils.h:200 * frame #7: 0x075c0a1d XUL`audiounit_stream_get_position(stm=0x8183d830, position=0xb34ab390) + 45 at cubeb_audiounit.cpp:1511 frame #8: 0x075bcefb XUL`cubeb_stream_get_position(stream=0x8183d830, position=0xb34ab390) + 75 at cubeb.c:301 frame #9: 0x04a4f256 XUL`int mozilla::AudioStream::InvokeCubeb<int (*)(cubeb_stream*, unsigned long long*), unsigned long long*>(this=0x80f4e010, aFunction=(XUL`cubeb_stream_get_position at cubeb.c:296), aArgs=0xb34ab38c)(cubeb_stream*, unsigned long long*), unsigned long long*&&) + 102 at AudioStream.cpp:317 frame #10: 0x04a4ef9c XUL`mozilla::AudioStream::GetPositionInFramesUnlocked(this=0x80f4e010) + 124 at AudioStream.cpp:502 frame #11: 0x04a4eea5 XUL`mozilla::AudioStream::GetPosition(this=0x80f4e010) + 53 at AudioStream.cpp:480 frame #12: 0x04da3cd0 XUL`mozilla::media::DecodedAudioDataSink::GetPosition(this=0x7cbe2a00) + 80 at DecodedAudioDataSink.cpp:110 frame #13: 0x04da0d6b XUL`mozilla::media::AudioSinkWrapper::GetPosition(this=0x7ee116d0, aTimeStamp=0xb34ab640) const + 219 at AudioSinkWrapper.cpp:88 frame #14: 0x04dacb9e XUL`mozilla::media::VideoSink::UpdateRenderedVideoFrames(this=0x87dd9830) + 238 at VideoSink.cpp:405 frame #15: 0x04dac744 XUL`mozilla::media::VideoSink::Start(this=0x87dd9830, aStartTime=0, aInfo=0x7f966c24) + 644 at VideoSink.cpp:202 frame #16: 0x04affd93 XUL`mozilla::MediaDecoderStateMachine::StartMediaSink(this=0x7f966a00) + 291 at MediaDecoderStateMachine.cpp:2550 frame #17: 0x04affbac XUL`mozilla::MediaDecoderStateMachine::MaybeStartPlayback(this=0x7f966a00) + 844 at MediaDecoderStateMachine.cpp:2049 frame #18: 0x04b061ba XUL`mozilla::MediaDecoderStateMachine::DecodingState::Step(this=0x87adc220) + 122 at MediaDecoderStateMachine.cpp:452 frame #19: 0x04b03476 XUL`mozilla::MediaDecoderStateMachine::RunStateMachine(this=0x7f966a00) + 182 at MediaDecoderStateMachine.cpp:2759 frame #20: 0x04bbf937 XUL`decltype(o=0x7f966a00, m=c0 33 b0 04 00 00 00 00, args=0x80f575a8, (null)=IndexSequence<> @ 0xb34ab900).*fp0(Get<>(fp1).PassAsParameter())) mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::MediaDecoderStateMachine, void (mozilla::MediaDecoderStateMachine::*)()>(mozilla::MediaDecoderStateMachine*, void (mozilla::MediaDecoderStateMachine::*)(), mozilla::Tuple<>&, mozilla::IndexSequence<>) + 103 at nsThreadUtils.h:729 frame #21: 0x04bbf8c0 XUL`_ZN7mozilla6detail23RunnableMethodArgumentsIJEE5applyINS_24MediaDecoderStateMachineEMS4_FvvEEEDTcl9applyImplfp_fp0_dtdefpT10mArgumentscvNS_13IndexSequenceIJEEE_EEEPT_T0_(this=0x80f575a8, o=0x7f966a00, m=c0 33 b0 04 00 00 00 00) + 80 at nsThreadUtils.h:735 frame #22: 0x04bbf7f6 XUL`mozilla::detail::RunnableMethodImpl<void (mozilla::MediaDecoderStateMachine::*)(), true, false>::Run(this=0x80f57590) + 134 at nsThreadUtils.h:764 frame #23: 0x00791b50 XUL`mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run(this=0x80fbf0b0) + 240 at TaskDispatcher.h:192 frame #24: 0x0077c162 XUL`mozilla::TaskQueue::Runner::Run(this=0x85f9d1e0) + 786 at TaskQueue.cpp:236 frame #25: 0x0078e039 XUL`nsThreadPool::Run(this=0x7eeaa260) + 1545 at nsThreadPool.cpp:225 frame #26: 0x0078e34a XUL`non-virtual thunk to nsThreadPool::Run(this=0x7eeaa260) + 26 at nsThreadPool.cpp:152 frame #27: 0x00788c42 XUL`nsThread::ProcessNextEvent(this=0x89269340, aMayWait=true, aResult=0xb34abce6) + 1362 at nsThread.cpp:1082 frame #28: 0x00817913 XUL`NS_ProcessNextEvent(aThread=0x89269340, aMayWait=true) + 163 at nsThreadUtils.cpp:290 frame #29: 0x0126838f XUL`mozilla::ipc::MessagePumpForNonMainThreads::Run(this=0x891b5b80, aDelegate=0x7d298290) + 1199 at MessagePump.cpp:368 frame #30: 0x0116e0ae XUL`MessageLoop::RunInternal(this=0x7d298290) + 142 at message_loop.cc:232 frame #31: 0x0116dff7 XUL`MessageLoop::RunHandler(this=0x7d298290) + 23 at message_loop.cc:225 frame #32: 0x0116df9c XUL`MessageLoop::Run(this=0x7d298290) + 44 at message_loop.cc:205 frame #33: 0x00784bff XUL`nsThread::ThreadFunc(aArg=0x89269340) + 575 at nsThread.cpp:465 frame #34: 0x00436345 libnss3.dylib`_pt_root(arg=0x892171c0) + 453 at ptthread.c:216 frame #35: 0x9f76a11b libsystem_pthread.dylib`_pthread_body + 184 frame #36: 0x9f76a063 libsystem_pthread.dylib`_pthread_start + 243 frame #37: 0x9f76993e libsystem_pthread.dylib`thread_start + 34 (lldb)

doh... stm->mutex = owned_critical_section(); destructor of owned_critical_section will be called, making the mutex invalid.. how can this work on 64 bits??

we have the same issue on windows. We copy a CRITICAL_SECTION to immediately destroy it. The CRITICAL_SECTION object is then used as if it had been properly constructed and initialized, when it is not. It's a wonder this ever worked on any platforms :( I should have looked at cubeb upstream, this is fixed in https://github.com/kinetiknz/cubeb/commit/22557d466eceb6ff6ba70ae30d2dcd87648cde0b though, I don't find their solution particularly elegant.

Comment on attachment 8801982 [details] Bug 1308418: [cubeb] P1. Fix mutex construction. We'll take the fix from upstream.

Comment on attachment 8801983 [details] Bug 1308418: [cubeb] P2. Remove redundant assertion. We'll take the fix from upstream.

This has already been reviewed and merged upstream, so just looking for a rubber stamp before pushing to m-c and requesting uplift for m-a and m-b. https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc18975ff65cb6ad97566a0bb9ffae39e860f4b9

Comment on attachment 8802367 [details] [diff] [review] bug1308418_v0.patch Review of attachment 8802367 [details] [diff] [review]: ----------------------------------------------------------------- Personally, I find this fix particularly ugly... especially the cubeb_wasapi bit... it's all C++ code, having a proper constructor is far less error prone ::: media/libcubeb/src/cubeb_utils_unix.h @@ +82,5 @@ > pthread_mutex_t mutex; > + > + // Disallow copy and assignment because pthread_mutex_t cannot be copied. > + owned_critical_section(const owned_critical_section&); > + owned_critical_section& operator=(const owned_critical_section&); For what it's worth. the operator we should have to be worried about here is the move assignement (operator=(owned_critical_section&&)) ::: media/libcubeb/src/cubeb_wasapi.cpp @@ +1740,5 @@ > close_wasapi_stream(stm); > } > > + // Need to call dtor to free the resource in owned_critical_section. > + stm->stream_reset_lock.~owned_critical_section(); booo

Pushed by mgregan@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6a9aa6f3d765 Avoid double-constructing owned_critical_section via copy constructor. r=jya

Comment on attachment 8802367 [details] [diff] [review] bug1308418_v0.patch Approval Request Comment [Feature/regressing bug #]: bug 1290425 [User impact if declined]: no audio playback on 32-bit OS X, possibly same issue on other OS X and Windows platforms, possibly resources leaks every time audio playback is started [Describe test coverage new/current, TreeHerder]: n/a [Risks and why]: very low risk, reverts construction of mutex wrapper to safer version [String/UUID change made/needed]: none

Hi Mihai, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks! Hi Julien, could you please accept the beta uplift after Mihai has verified this fix works and there are no unexpected regressions? This will save me time my Thursday morning. :) Thanks!

I managed to test this issue on Firefox Latest Nightly (20161019030208) and on the Latest Tinderbox build (20161019183138) and the issue is not reproducible. Note that the issue is not reproducible on Firefox 51.0a2 (2016-10-19). While testing I noticed that in "About Nightly" section, the build is still displayed as been on 64-bit, although I've opened the Latest Nightly in 32-bit mode. On Firefox Latest Aurora is the same behaviour. Is this behaviour expected? Please let me know if I can help any further with the investigation.

Mihai, just to clarify, were you able to reproduce the issue with an older nightly build?

Apparently this issue is reproducible only on Firefox 50 Builds (beta). I've just tested this issue on Firefox 52.0a1 (20161001030430) and the issue is not reproducible.

Comment on attachment 8802367 [details] [diff] [review] bug1308418_v0.patch Fix mutex initialization, uplift to aurora51/beta50.

has problems uplifting grafting 370393:6a9aa6f3d765 "Bug 1308418 - Avoid double-constructing owned_critical_section via copy constructor. r=jya" merging media/libcubeb/src/cubeb_wasapi.cpp merging media/libcubeb/update.sh warning: conflicts while merging media/libcubeb/update.sh! (edit, then use 'hg resolve --mark') abort: unresolved conflicts, can't continue (use 'hg resolve' and 'hg graft --continue')

(In reply to Mihai Boldan, QA [:mboldan] from comment #32) > Apparently this issue is reproducible only on Firefox 50 Builds (beta). > I've just tested this issue on Firefox 52.0a1 (20161001030430) and the issue > is not reproducible. I could reproduce the problem on nightly in a few seconds. Make sure the box "run in 32 bit" is checked. Start nightly. Attempt to play any audio or video file -> playback won't start. Additionally, you won't be able to quit nightly anymore. It will deadlock. You can also start nightly on the command line doing: arch -i386 /path/to/Nightly.app/Content/MacOS/firefox Beware that if you restart Firefox from within Firefox, it will be restarted in 64 bits mode.

Patch rebased for mozilla-aurora.

Patch rebased for mozilla-beta.

https://hg.mozilla.org/releases/mozilla-aurora/rev/3a45c899d5015ba64e1cdbe206687951561e6fca https://hg.mozilla.org/releases/mozilla-beta/rev/e4e6022059e5c35d3b1bbc731b1f68f266302be3

(In reply to Jean-Yves Avenard [:jya] from comment #35) > (In reply to Mihai Boldan, QA [:mboldan] from comment #32) > > Apparently this issue is reproducible only on Firefox 50 Builds (beta). > > I've just tested this issue on Firefox 52.0a1 (20161001030430) and the issue > > is not reproducible. > > I could reproduce the problem on nightly in a few seconds. > Make sure the box "run in 32 bit" is checked. Start nightly. Attempt to play > any audio or video file -> playback won't start. Additionally, you won't be > able to quit nightly anymore. It will deadlock. > > You can also start nightly on the command line doing: > arch -i386 /path/to/Nightly.app/Content/MacOS/firefox > > Beware that if you restart Firefox from within Firefox, it will be restarted > in 64 bits mode. I've tried to reproduce the issue on Firefox Latest Nightly by using both methods (checking 'Open in 32-bit mode' from Get Info and by starting FF from the Terminal, using the provided command line) without success. Can you please tell me how to verify that the build started in 32-bit mode? I've used the STR from Comment 0. Did you used other STR in order to reproduce this issue? Tests were performed on Mac OS X 10.11.6.

Start the activity monitor. In the CPU view; there's a type column. It will say 32 bit or 64 bit.

Thanks Jean for the info. It seems that the Latest Nightly and the Latest Aurora builds were opened in 64-bit mode, despite the fact that I previously choose to open the builds in 32-bit mode. It seems that e10s automatically changes the build to 64-bit mode (I will log a new bug for this). After disabling e10s, the builds were opened in 32-bit mode. As a conclusion - the issue is reproducible on the Latest Aurora and on Firefox Nightly 52.0a1(2016-10-01)(32-bit). Also I noticed that the 32/64 bit mode is correctly displayed in About Nightly window. The issue is not reproducible any more on Firefox Latest Nightly 52.0a1(2016-10-20)(32-bit).

After more investigation, it seems that starting FF using Profile Manager causes this issue, not e10s.

(In reply to Mihai Boldan, QA [:mboldan] from comment #41) > As a conclusion - the issue is reproducible on the Latest Aurora and on > Firefox Nightly 52.0a1(2016-10-01)(32-bit). > Also I noticed that the 32/64 bit mode is correctly displayed in About > Nightly window. > > The issue is not reproducible any more on Firefox Latest Nightly > 52.0a1(2016-10-20)(32-bit). Thanks Jean-Yves and Mihai!

The issue is no longer reproducible on Firefox 50.0b10, Firefox 51.0a2(2016-10-25), Firefox 52.0a1(2016-10-24), using the 32-bit mode, on Mac OS X 10.11.6. I am marking this issue Verified Fixed.

(In reply to Jean-Yves Avenard [:jya] from comment #21) > we have the same issue on windows. We copy a CRITICAL_SECTION to immediately > destroy it. The CRITICAL_SECTION object is then used as if it had been > properly constructed and initialized, when it is not. > > It's a wonder this ever worked on any platforms :( > > I should have looked at cubeb upstream, this is fixed in > https://github.com/kinetiknz/cubeb/commit/ > 22557d466eceb6ff6ba70ae30d2dcd87648cde0b > > though, I don't find their solution particularly elegant. I think it's actually fixed by bug 1308423. I wonder why it didn't merge back to m-c.

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #45) > I think it's actually fixed by bug 1308423. I wonder why it didn't merge > back to m-c. The linked fix is the fix from bug 1308423, it was merged upstream but Gecko's copy of libcubeb hadn't been updated yet.