FEXServer: Listen on both abstract & named sockets

[asahilina]

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.

[Sonicadvance1]

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]

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 std::filesystem::temp_directory_path()... (this was actually already used here in the past when the socket was not abstract, but I think that glibc test didn't exist back then).

[asahilina]

Oookay, that's another issue, but now I don't know why it didn't fail before. Third time's the charm?

[asahilina]

And now the glibc thing again... I have no idea what it could be then. How do I run those tests locally?

[Sonicadvance1]

Build FEX with -DENABLE_GLIBC_ALLOCATOR_HOOK_FAULT=True -DENABLE_JEMALLOC_GLIBC_ALLOC=False to enable the glibc fault checking. and then for the gcc tests specifically that are failing would be ninja gcc_target_tests_64

[asahilina]

Oof, it was both std::filesystem::temp_directory_path() as I suspected and strerror(). Which means this was always broken, it's just that the messages never got printed during the tests until now... and I had a missing errno check that was causing one of them to log unnecessarily.

[Sonicadvance1]

Looks like we should add std::filesystem::temp_directory_path to the Programming Concerns document.

[asahilina]

Added to the docs.