More robust runtime executable path detection
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Medium
|
Unassigned |
Bug Description
On some operating systems os_get_
If sbcl isn't able to find the executable path using the os-dependent method then it may still be possible to find a path to the executable on non-win32 OSes using argv[0], searching the PATH environment variable if necessary. This method is somewhat error-prone, so it would be better to add a new function to check the build_id, and then to call it both when checking for an embedded core on startup and when saving an executable core from save-lisp-and-die.
Attached is a patch which does this, as well as removing the now-superfluous warning when the NetBSD/OpenBSD os_get_
Changed in sbcl: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
tags: | added: patch runtime |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
Attached is the previous patch, updated to account for how os_get_ runtime_ executable_ path() is used to set *CORE-PATHNAME*.
A flag is added to o_g_r_e_p() to request that the returned path is externally usable, ie: suitable for use in a shebang line.
The NetBSD/OpenBSD and SunOS implementations, which return a magic path in /proc that is only valid for the current process, are changed to return NULL if the flag is true. All the other OS's implementations look fine just by reading the code but I haven't actually checked any of them.
Change the code in main() to always try to save the argv[0] derived runtime path, in case o_g_r_e_p() fails later on when an external path is needed.
Change the *CORE-PATHNAME* setting code to try the saved argv[0] derived path if O-G-R-E-P fails.
While working on this I noticed what may be a small memory leak in the *CORE-PATHNAME* setting code in src/code/ common- os.lisp. o_g_r_e_p() returns either NULL or malloc()-allocated memory, but when it is called from lisp there doesn't seem to be any attempt to free this memory.