Closed Ptival closed 3 years ago
alexdima
commented
3 years ago @deepak1556 We are now deleting the environment variable DYLD_LIBRARY_PATH when spawning the extension host due to extension host crashes we have seen where Electron was respecting it. Is there a safe way where we could allow it again? Would it be possible to disable respecting DYLD_LIBRARY_PATH in Electron so we can revert that change?
deepak1556
commented
3 years ago Is there a safe way where we could allow it again?
We could copy the value of DYLD_LIBRARY_PATH into DYLD_FALLBACK_LIBRARY_PATH before launching the extension host process, not sure if it will cover all the cases. But based on dlopen docs, it is always the end node that gets searched, so should be a safe fallback.
dlopen() searches for a compatible Mach-O file in the directories specified by a set of environment variables and the process's current working directory. When set, the environ-
ment variables contain a colon-separated list of directory paths, which can be absolute or relative to the current working directory.
When path does not contain a slash character (i.e. it is just a leaf name), dlopen() searches the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH,
$DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH.Would it be possible to disable respecting DYLD_LIBRARY_PATH in Electron so we can revert that change?
No its a OS thing. The issue is not directly linked to Electron, when we create the extension host as a fork of the renderer process, the renderer helper executable is dynamically linked to a number of system libraries
https://github.com/microsoft/vscode/issues/104525 is a case where the libraries from DYLD_LIBRARY_PATH where messing with the symbols of the above dependent libraries. We decided to not respect this variable inside vscode to prevent such crashes.
deepak1556
commented
3 years ago @Ptival does DYLD_FALLBACK_LIBRARY_PATH work for your use case ?
In https://github.com/microsoft/vscode/issues/88306 the ability to pass
DYLD_LIBRARY_PATHto spawned processes was fixed on Mac by declaring proper entitlements.In fixing https://github.com/microsoft/vscode/issues/104525 however, it was decided to explicitly unset this variable when spawning processes, which is a little weird:
https://github.com/microsoft/vscode/blob/82767cc1d7bf8cdea0f2897276d5d15aee91f3d9/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts#L176-L180
This unfortunately causes problems. In my case, the Haskell Language Server spawns the
cabaltool to compile Haskell files, and that tool needs to receive proper values forDYLD_LIBRARY_PATHfor compilation to succeed. The removal of that variable explicitly seems a little bit questionable, so could we at least have some sort of option to change this behavior?