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

ERL-49: Large halt() exit status not checked #3108

Closed
OTP-Maintainer opened this issue Dec 2, 2015 · 3 comments
Closed

ERL-49: Large halt() exit status not checked #3108

OTP-Maintainer opened this issue Dec 2, 2015 · 3 comments
Assignees
Labels
bug Issue is reported as a bug priority:medium team:VM Assigned to OTP team VM
Milestone

Comments

@OTP-Maintainer
Copy link

Original reporter: richardc
Affected version: OTP-18.2
Fixed in version: OTP-18.3
Component: erts
Migrated from: https://bugs.erlang.org/browse/ERL-49


In halt/1 and halt/2, if the given Status is a fixnum, it gets negated and cast to an int in the function halt_1 (bif.c), which typically truncates it to 32 bits. If the original value was large enough (e.g. 7FFFFFFE), the negated and truncated value can overlap with the definitions of ERTS_ABORT_EXIT and friends (sys.h), which are in the range INT_MIN...(INT_MIN+2), causing the system to exit with a crash dump and/or core dump.

Example:
{code:erlang}
1> halt(16#7FFFFFFE).
Crash dump is being written to: /tmp/erl_crash_dump...done

1> halt(16#7FFFFFFF).
Aborted (core dumped)

1> halt(16#80000001).
Crash dump is being written to: /tmp/erl_crash_dump...done
Aborted (core dumped)
{code}

Possible solutions that I've looked at:
* Set a hard upper limit for the halt() status codes, same on all Erlang systems; e.g., 7FFFFFF0. Consistent, but not so nice on systems that want to use a full 32-bit range for error codes.
* Check for an upper limit of e.g. INT_MAX-7, which could potentially vary between systems. Inconsistent from the Erlang programmer's view, awkward to document, and still doesn't allow full 32 bit range on normal systems.
* Silently truncate the value to at most N bits where N is as large as possible but not large enough to cause the value to wrap. Inconsistent, hackish, and doesn't allow full 32 bits.
* Rewrite the mechanism for setting these internal exit flags (ERTS_INTR_EXIT, ERTS_ABORT_EXIT, ERTS_DUMP_EXIT) to separate them from the exit code, so at least 32 bits can be guaranteed if the OS allows it. Consistent and much nicer, but I don't want to attack that part of the code without some feedback from the OTP devs first.

@OTP-Maintainer
Copy link
Author

richardc said:

Related to https://github.com/erlang/otp/pull/911.

@OTP-Maintainer
Copy link
Author

bruce said:

Just a tip for pull requests, if you mention "ERL-49" in the description or title of the Github pull request, it will be shown here automatically on JIRA. 

Example: http://bugs.erlang.org/browse/ERL-43

@OTP-Maintainer
Copy link
Author

sverker said:

Any non negative exit status is now accepted by halt. High order bits will be truncated if not supported by the OS.

@OTP-Maintainer OTP-Maintainer added bug Issue is reported as a bug team:VM Assigned to OTP team VM priority:medium labels Feb 10, 2021
@OTP-Maintainer OTP-Maintainer added this to the OTP-18.3 milestone Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug priority:medium team:VM Assigned to OTP team VM
Projects
None yet
Development

No branches or pull requests

2 participants