Closed Bug 1342843 Opened 6 years ago Closed 6 years ago

Enable CrossProcessSemaphore on all BSDs

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox54 --- fixed

People

(Reporter: jbeich, Unassigned)

References

Details

Attachments

(1 file)

Bug 1342843 - Enable CrossProcessSemaphore on all BSDs.
59 bytes, text/x-review-board-request
mattwoodrow
: review+
Details 
Unlike PTHREAD_PROCESS_SHARED all OpenBSD and NetBSD support sem_init(pshared=1). layers.enable-tiles=false is default, so users may hit bug 1340076.
Comment on attachment 8841438 [details]
Bug 1342843 - Enable CrossProcessSemaphore on all BSDs.

Martin, Landry, can you check before/after applying the patch for regressions? I'm not sure but it may require e10s and OpenGL compositing enabled.
Attachment #8841438 - Flags: feedback?(martin)
Attachment #8841438 - Flags: feedback?(landry)
Comment on attachment 8841438 [details]
Bug 1342843 - Enable CrossProcessSemaphore on all BSDs.

https://reviewboard.mozilla.org/r/115662/#review117046
Attachment #8841438 - Flags: review?(matt.woodrow) → review+
Right now without patches nightly crashes at startup in CrossProcessSemaphore() anyway.
Indeed. When CrossProcessSemaphore is N/A crash occurs on startup regardless of e10s or HW_COMPOSITING.
Keywords: checkin-needed
Attachment #8841438 - Flags: feedback?(martin)
Attachment #8841438 - Flags: feedback?(landry)
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/596b62a60edf
Enable CrossProcessSemaphore on all BSDs. r=mattwoodrow
Keywords: checkin-needed
Fwiw; still segfaults even with this patch (and #1335284), without profile:

#0  0x00000d4f18d5ed6b in mozilla::CrossProcessSemaphore::CrossProcessSemaphore () from /tmp/firefox/libxul.so.1.0
#1  0x00000d4f194a1c88 in mozilla::layers::ContentClientRemoteBuffer::CreateBackBuffer () from /tmp/firefox/libxul.so.1.0
#2  0x00000d4f194a1fd6 in mozilla::layers::ContentClientRemoteBuffer::CreateBuffer () from /tmp/firefox/libxul.so.1.0
#3  0x00000d4f1944aeb4 in mozilla::layers::RotatedContentBuffer::BeginPaint () from /tmp/firefox/libxul.so.1.0
#4  0x00000d4f194aaf42 in mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer () from /tmp/firefox/libxul.so.1.0
#5  0x00000d4f1949d4e8 in mozilla::layers::ClientPaintedLayer::PaintThebes () from /tmp/firefox/libxul.so.1.0
#6  0x00000d4f1949d932 in mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback () from /tmp/firefox/libxul.so.1.0
#7  0x00000d4f194ad56d in mozilla::layers::ClientContainerLayer::RenderLayer () from /tmp/firefox/libxul.so.1.0
#8  0x00000d4f1949c0e6 in mozilla::layers::ClientLayerManager::EndTransactionInternal () from /tmp/firefox/libxul.so.1.0
#9  0x00000d4f1949c28a in mozilla::layers::ClientLayerManager::EndTransaction () from /tmp/firefox/libxul.so.1.0
#10 0x00000d4f1b047ff0 in nsDisplayList::PaintRoot () from /tmp/firefox/libxul.so.1.0
#11 0x00000d4f1add8dd6 in nsLayoutUtils::PaintFrame () from /tmp/firefox/libxul.so.1.0
#12 0x00000d4f1ad8dbbe in mozilla::PresShell::Paint () from /tmp/firefox/libxul.so.1.0
#13 0x00000d4f1ab052ac in nsViewManager::ProcessPendingUpdatesPaint () from /tmp/firefox/libxul.so.1.0
#14 0x00000d4f1ab04e49 in nsViewManager::ProcessPendingUpdatesForView () from /tmp/firefox/libxul.so.1.0
#15 0x00000d4f1ab05f9d in nsViewManager::ProcessPendingUpdates () from /tmp/firefox/libxul.so.1.0
#16 0x00000d4f1ad5c24d in nsRefreshDriver::Tick () from /tmp/firefox/libxul.so.1.0
#17 0x00000d4f1ad5f769 in mozilla::RefreshDriverTimer::TickRefreshDrivers () from /tmp/firefox/libxul.so.1.0
#18 0x00000d4f1ad5f4ef in mozilla::RefreshDriverTimer::Tick () from /tmp/firefox/libxul.so.1.0
#19 0x00000d4f1ad60318 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver ()
   from /tmp/firefox/libxul.so.1.0
#20 0x00000d4f1ad5e834 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::ParentProcessVsyncNotifier::Run ()
   from /tmp/firefox/libxul.so.1.0
#21 0x00000d4f1882c421 in nsThread::ProcessNextEvent () from /tmp/firefox/libxul.so.1.0
#22 0x00000d4f1882b385 in NS_ProcessNextEvent () from /tmp/firefox/libxul.so.1.0
#23 0x00000d4f1ba38e57 in nsXULWindow::ShowModal () from /tmp/firefox/libxul.so.1.0
#24 0x00000d4f1bd43939 in nsWindowWatcher::OpenWindowInternal () from /tmp/firefox/libxul.so.1.0
#25 0x00000d4f1bd41f3a in nsWindowWatcher::OpenWindow () from /tmp/firefox/libxul.so.1.0
#26 0x00000d4f1bd6c80b in _ZL18ShowProfileManagerP24nsIToolkitProfileServiceP19nsINativeAppSupport ()
   from /tmp/firefox/libxul.so.1.0
#27 0x00000d4f1bd69ac0 in XREMain::XRE_mainStartup () from /tmp/firefox/libxul.so.1.0
#28 0x00000d4f1bd6b833 in XREMain::XRE_main () from /tmp/firefox/libxul.so.1.0
#29 0x00000d4f1bd6be50 in XRE_main () from /tmp/firefox/libxul.so.1.0
#30 0x00000d4c76a00e19 in main () from /tmp/firefox/firefox


Iirc, hw/opengl compositing is disabled by default on openbsd (at least that's what i have in about:support on 51.0) - dunno if that matters.
(In reply to Landry Breuil (:gaston) from comment #7)
> #0  0x00000d4f18d5ed6b in
> mozilla::CrossProcessSemaphore::CrossProcessSemaphore () from
> /tmp/firefox/libxul.so.1.0

ipc/glue/CrossProcessSemaphore_posix.cpp has a few MOZ_CRASH() lines. Try injecting printfs or build with debug symbols (use less memory-hungry linker) to figure out which.
https://hg.mozilla.org/mozilla-central/rev/596b62a60edf
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox54: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
aurora starts fine, so at least that's a problem only in nightly - one less thing to worry about given the upcoming merges. Should i reopen this bug ?
Well, it crashes because sem_init() returns EPERM, because we don't seem to allow shared semaphores:

https://github.com/openbsd/src/blob/master/lib/librthread/rthread_sem.c#L114
Seems that's this way on OpenBSD since 3+ years because shared semaphores dont seem to really work, cf https://github.com/openbsd/src/commit/378aca9a01367d9c3e50a8eb577043d1309179b0

In the meantime, tried adding layers.enable-tiles=true and/or browser.tabs.remote.autostart=false (if that's still the way to disable e10s) to prefs.js but that still crashes the same.
e10s on Nightly/Aurora is controlled by browser.tabs.remote.autostart.2, not by browser.tabs.remote.autostart which remains false. See the comment in browser/app/profile/firefox.js.

Can you figure out where it crashes now and add a few printfs? CrossProcessSemaphore shouldn't be used with layers.enable-tiles=true (or it'd break OS X) and CrossProcessMutex shouldn't be used with layers.progressive-paint=false.
Good to know, didnt follow that the config knob changed.

So nightly starts fine with browser.tabs.remote.autostart.2=false + layers.enable-tiles=true, and crashes (still on sem_init) with browser.tabs.remote.autostart.2=false + layers.enable-tiles=false.
Landry, can you file a new bug for layers.enable-tiles=true by default on OpenBSD via modules/libpref/init/all.js? Alternatively, OpenBSD can try to fix sem_init(pshared=1) in -CURRENT before 2017-06-13.

Why OpenBSD didn't bother to document sem_init() brokeness or EPERM overload in the manpage? Other Unices may[1] return ENOTSUP if pshared has a non-zero value, even OpenBSD uses it for PTHREAD_PROCESS_SHARED. And POSIX uses EPERM for "the process lacks appropriate privileges to initialize the semaphore".

[1] https://www.novell.com/documentation/developer/libc/libc_vol2/data/akppu0q.html

(In reply to Landry Breuil (:gaston) from comment #18)
> Good to know, didnt follow that the config knob changed.

Does e10s not work at all on OpenBSD? Why?
(In reply to Jan Beich from comment #19)
> Landry, can you file a new bug for layers.enable-tiles=true by default on
> OpenBSD via modules/libpref/init/all.js? Alternatively, OpenBSD can try to
> fix sem_init(pshared=1) in -CURRENT before 2017-06-13.

What's specific about this date ? What is this particular knob doing and how is it related to e10s ?

> Why OpenBSD didn't bother to document sem_init() brokeness or EPERM overload
> in the manpage? Other Unices may[1] return ENOTSUP if pshared has a non-zero
> value, even OpenBSD uses it for PTHREAD_PROCESS_SHARED. And POSIX uses EPERM
> for "the process lacks appropriate privileges to initialize the semaphore".

*shrug*. If only i knew..

> [1]
> https://www.novell.com/documentation/developer/libc/libc_vol2/data/akppu0q.
> html
> 
> (In reply to Landry Breuil (:gaston) from comment #18)
> > Good to know, didnt follow that the config knob changed.
> 
> Does e10s not work at all on OpenBSD? Why?

It worked in my initial testing some releases/months ago, didnt have time to retest recently.
(In reply to Landry Breuil (:gaston) from comment #20)
> > Alternatively, OpenBSD can try to fix sem_init(pshared=1) in -CURRENT before 2017-06-13.
> 
> What's specific about this date ?

Bug 1325227 is riding on Firefox 54 train which is scheduled on that date.

https://wiki.mozilla.org/RapidRelease/Calendar

> What is this particular knob doing and how is it related to e10s ?

I don't know. Maybe look up the history (e.g. bug 739679, bug 895358, bug 982338), use $search_engine[1] or benchmark via "./mach talos-test".

[1] https://en.wikipedia.org/wiki/Tiled_rendering
    https://wiki.mozilla.org/B2G/TiledLayers
    http://chrislord.net/index.php/2012/10/17/progressive-tile-rendering/
Depends on: 1345899
No longer depends on: 1345899
please revert
(In reply to coypu from comment #22)
> please revert

Can you file a separate bug and properly document the issue? Switching to CrossProcessSemaphore_unimplemented.cpp would guarantee Firefox crashes unless you do something like bug 1345899.
You need to log in before you can comment on or make changes to this bug.