FEXServer: Listen on both abstract & named sockets #4159
Conversation
|
Looks like you got clipped by the glibc fault test path. Will need a backtrace to see where glibc is attempting to do an allocation in this mode. |
asahilina
force-pushed
the
fexserver-two-sockets
branch
from
6e06cd4
to
6bc8107
Compare
|
I think I fixed it? I don't really know how to run the test, but the only code I can think of that would do allocations behind my back is |
Apparently this causes allocations which are banned in some paths?
Abstract sockets have one limitation: they are bound to a network namespace. Chromium/CEF sandboxes using a new netns, which breaks connecting to the FEXServer. To work around this, use and try *both* abstract and named sockets. As long as either the filesystem or the network is unsandboxed, things will work. If both are sandboxed, there isn't much we can do... but at that point we shouldn't be reinitializing the FEXServer connection anyway since the FS should be available on FEXInterpreter startup.
asahilina
force-pushed
the
fexserver-two-sockets
branch
from
6bc8107
to
2f8f479
Compare
|
Oookay, that's another issue, but now I don't know why it didn't fail before. Third time's the charm? |
|
And now the glibc thing again... I have no idea what it could be then. How do I run those tests locally? |
|
Build FEX with |
Abstract sockets have one limitation: they are bound to a network namespace. Chromium/CEF sandboxes using a new netns, which breaks connecting to the FEXServer.
To work around this, use and try both abstract and named sockets. As long as either the filesystem or the network is unsandboxed, things will work. If both are sandboxed, there isn't much we can do... but at that point we shouldn't be reinitializing the FEXServer connection anyway since the FS should be available on FEXInterpreter startup.