More robust runtime executable path detection

Bug #375549 reported by Josh Elsasser on 2009-05-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

On some operating systems os_get_runtime_executable_path() can fail. On some systems it is almost certain, such as OpenBSD/amd64 with the standard kernel. On HP/UX os_get_runtime_executable_path() is just a stub function which always returns a nonsense string.

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_runtime_executable_path() fails.

Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed
tags: added: patch runtime
Josh Elsasser (josh-elsasser) wrote :

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.

Josh Elsasser (josh-elsasser) wrote :

Has anyone had a chance to look at this? Any feedback or suggestions for a better way of doing this?

Nikodemus Siivola (nikodemus) wrote :


Changed in sbcl:
status: Confirmed → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers