Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

weird bug with custom toplevels #2979

Closed
vicuna opened this issue Oct 6, 2001 · 5 comments
Closed

weird bug with custom toplevels #2979

vicuna opened this issue Oct 6, 2001 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Oct 6, 2001

Original bug ID: 557
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello,

assume that I have a customized toplevel "mocaml" somewhere in my $PATH,
which also contains support for Tk.

Now I create another customized toplevel with the same name in another
directory, but without Tk-support:

ocamlmktop -custom -o mocaml

Now I write a small script "mocaml_test", which looks e.g. as follows
(set the script header to the toplevel without Tk-support):


#!/home/mottl/mocaml

print_endline "Hello world!"

After chmoding it executable, calling it directly will lead to the
following error (at least on my Linux-box and the Alpha):

Fatal error: unknown C primitive `camltk_return'

Renaming the toplevel to, say, "foobar" (not in path) and changing the
script header accordingly will lead to the intended result.

The upper example is actually a bit misleading, and it took me a while to
figure out what was happening, because the problem does not really have to
do with Tk-support: note that using the name of another binary in the path
(say, "cat") for the toplevel, is likely to result in the following error:

Fatal error: the file ./mocaml_test is not a bytecode executable file

It seems that the interpreter tries to find itself and unfortunately
does so in the PATH. There it will find the other executable instead,
which is probably the reason for the problems above.

Regards,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

@vicuna
Copy link
Author

vicuna commented Oct 26, 2001

Comment author: administrator

Hi Markus,

assume that I have a customized toplevel "mocaml" somewhere in my $PATH,
which also contains support for Tk.
Now I create another customized toplevel with the same name in another
directory, but without Tk-support:
ocamlmktop -custom -o mocaml
Now I write a small script "mocaml_test", which looks e.g. as follows
(set the script header to the toplevel without Tk-support):

#!/home/mottl/mocaml

print_endline "Hello world!"

After chmoding it executable, calling it directly will lead to the
following error (at least on my Linux-box and the Alpha):
Fatal error: unknown C primitive `camltk_return'
Renaming the toplevel to, say, "foobar" (not in path) and changing the
script header accordingly will lead to the intended result.

I was able to reproduce this behavior (under Linux). The problem is
that in your example, /home/mottl/mocaml is invoked by the kernel with
the 0-th argument argv[0] set to "mocaml", and not
"/home/mottl/mocaml" as one would have expected.

Caml custom bytecode executables do indeed need to look inside
"themselves" for reading the bytecode, and this is done by looking at
argv[0], use it as is if it's a full path, and search it in the
$PATH if it's a short name. While not bullet-proof, this strategy
worked well so far. When the executable is invoked from a shell,
either the shell provides a full path in argv[0], or it sets argv[0]
to the command name as typed by the user; in the latter case, either
it's a full path, or it is in $PATH.

What your example demonstrates is that the kernel doesn't follow this
convention when dealing with #! scripts. This is truly weird and I'll
have to look at the Linux kernel sources to confirm it. The bad thing
about this is that there is essentially no way for Caml to work around
this problem!

Cheers,

  • Xavier

@vicuna
Copy link
Author

vicuna commented Oct 26, 2001

Comment author: administrator

Hi Xavier,

On Fri, 26 Oct 2001, Xavier Leroy wrote:

What your example demonstrates is that the kernel doesn't follow this
convention when dealing with #! scripts. This is truly weird and I'll
have to look at the Linux kernel sources to confirm it. The bad thing
about this is that there is essentially no way for Caml to work around
this problem!

I have just tried other OSes and found out that the same problem appears
under Digital Unix 4.0e but not so under Solaris. It would be interesting
to verify whether any standard actually determines the right behaviour.
If yes, it might be worthwhile sending Linus a patch for the loader... ;)

Maybe this problem should be mentioned in the docs, i.e. that one
shouldn't choose names of other executables that may appear earlier
in $PATH.

Cheers,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

@vicuna
Copy link
Author

vicuna commented Oct 26, 2001

Comment author: administrator

I have just tried other OSes and found out that the same problem appears
under Digital Unix 4.0e but not so under Solaris.

Interesting. A look at the Linux sources reveal that this is
intentional behavior (although there are no comments to justify this
design :-)

For Linux, there is an alternative to relying on argv[0], which is to
read the symbolic link /proc/self/exe. It's very Linux-specific but
perhaps it is worth adding this as a special case to Caml's startup
code.

  • Xavier

@vicuna
Copy link
Author

vicuna commented Oct 26, 2001

Comment author: administrator

On Fri, 26 Oct 2001, Xavier Leroy wrote:

For Linux, there is an alternative to relying on argv[0], which is to
read the symbolic link /proc/self/exe. It's very Linux-specific but
perhaps it is worth adding this as a special case to Caml's startup
code.

Good idea! Most European academic institutions are intending to shift more
and more to Linux anyway (if they haven't already done so completely).

Cheers,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

@vicuna
Copy link
Author

vicuna commented Oct 30, 2001

Comment author: administrator

XL, 2001-10-30: for Linux, take contents of /proc/self/exe as argv[0]. For
other Unixes: no solution known.

@vicuna vicuna closed this as completed Oct 30, 2001
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant