Closed Bug 1342843 Opened 7 years ago Closed 7 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: 7 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.

Attachment

General

Creator:
Created:
Updated:
Size: