[Openmcl-devel] Running CCL as a CGI process is failing, the image can't be loaded

[Gary Byers]

When the CCL kernel is run with no arguments, it tries to load its
default heap image by

1) determining its own pathname
2) On Windows, removing the ".exe" suffix from the kernel's pathname
3) appending ".image"

The last 1 or two steps are pretty simple, but the first step can
be surprisingly difficult.  A Unix process is usually started when
the parent process does a "fork" system call (creating a copy of
itself) and the copy/child process does some flavor of "exec"
system call.  There are usually several variants of "exec" (differing
in such things as whether the PATH environment variable is searched
and in how the environment is handled), but those variants usually
all take arguments that include the path to the executable file
and a C array of C strings ("argv") used to provide arguments to
the process. (That array -or a copy of it - is accessable as an
argument to the C 'main()' function in the new process.)

Usually, the 0th element of the argv array is the same as the
path to the executable file, but this is just a convention.  (Shells
usually follow that convention, but I'd be willing to bet that the
CGI code that's trying to start CCL isn't doing so.)

On Linux, it's possible for a process to reliably determine the path
to its own executable file (by looking at kernel information maintained
in the /proc psuedo-filesystem.)  On other platforms, it either isn't
possible or I don't know how to do this.  (Darwin offers something
called "_NSGetExecutablePath()", but I'm not sure that it really does
anything besides look at argv[0] for you.)

In the absence of something more reliable, about all that the lisp
kernel can do is to look at the 0th element of the argv vector that
its main function got as an argument in order to determine its own
pathname (step 1 above).  If that doesn't return an accurate answer,
then the image name returned in step 3 won't be correct, either.

I suppose that there are other things (symbolic links and whether
they are or aren't being followed) that can confuse the issue, but
if the lisp kernel that the CGI mechanism is exec'ing and the heap
image that it should load by default are in the same directory and
the heap image isn't being found, then it seems most likely that
that failure is due to the fact that the kernel can't reliably
determine its own pathname, quite possibly because the exec() call
that starts the process doesn't set the 0th element of the argv
vector to the executable file's pathname.  If the CGI mechanism
lets you pass arguments to the process, then passing the image
file as an argument would be one workaround; if it doesn't, then
executing a shell script that passes those arguments would be another.)

If this is indeed the problem, then I'd blame neither CCL nor Apache
for it, but instead blame "most Unices, for not offering a reliable
way for a process to determine its exectable's filename", or "me,
for not knowing how to do that on whatever platform you're using."

On Thu, 14 May 2009, Douglas Brunner wrote:

> I've tried to set up CCL to run as a CGI process to do some web
> development. I compiled a very simple program which just displays a
> header and a test string. Running the executable as myself, and as
> www-data (apache user) from the terminal work as expected, but when
> running it through the browser Apache always reports an error saying
> that the image can't be loaded.
>
> I'm wondering where I should be looking, at Apache, or at CCL.
>
> I've brought this up at a forum
> (http://lispforum.com/viewtopic.php?f=2&t=342), there's more info
> about the problem there.
>
> Thanks for any help.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>