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

The DefaultStackTraceElementObject.getExecutableName breaks the contract of InteropLibrary #7359

Closed
radeusgd opened this issue Sep 6, 2023 · 0 comments
Labels

Comments

@radeusgd
Copy link
Contributor

radeusgd commented Sep 6, 2023

I've been encountering this issue running the OpenJDK Runtime Environment GraalVM CE 17.0.7+7.1 (build 17.0.7+7-jvmci-23.0-b12) version, but I can confirm that it is still present in the latest sources on the master branch.

/**
* Returns {@code true} if the receiver has an executable name. Invoking this message does not
* cause any observable side-effects. Returns {@code false} by default.
*
* @see #getExecutableName(Object)
* @since 20.3
*/
@Abstract(ifExported = {"getExecutableName"})
public boolean hasExecutableName(Object receiver) {
return false;
}
/**
* Returns executable name of the receiver. Throws {@code UnsupportedMessageException} when the
* receiver is has no {@link #hasExecutableName(Object) executable name}. The return value is an
* interop value that is guaranteed to return <code>true</code> for {@link #isString(Object)}.
*
* @see #hasExecutableName(Object)
* @since 20.3
*/
@Abstract(ifExported = {"hasExecutableName"})
public Object getExecutableName(Object receiver) throws UnsupportedMessageException {
throw UnsupportedMessageException.create();
}

The contract of InteropLibrary says that if the receiver has no executable name (i.e. hasExecutableName(receiver) == false), then getExecutableName throws UnsupportedMessageException. It also says that otherwise, "The return value is an interop value that is guaranteed to return true for isString".

However, the code for DefaultStackTraceElementObject violates this contract:

final class DefaultStackTraceElementObject implements TruffleObject {
private final RootNode rootNode;
private final SourceSection sourceSection;
DefaultStackTraceElementObject(RootNode rootNode, SourceSection sourceSection) {
this.rootNode = rootNode;
this.sourceSection = sourceSection;
}
@ExportMessage
@TruffleBoundary
@SuppressWarnings("static-method")
boolean hasExecutableName() {
return rootNode.getName() != null;
}
@ExportMessage
@TruffleBoundary
Object getExecutableName() {
return rootNode.getName();
}

When the rootNode.getName() == null, it does report hasExecutableName to be false, but asking for it, instead of throwing UnsupportedMessageException as required by contract, it returns null - which is not an interop value that "is guaranteed to return true for isString".

Thus code relying on the contract of InteropLibrary, assuming that getExecutableName either returns a valid text value or throws an exception, breaks when it encounters a DefaultStackTraceElementObject whose rootNode.getName() == null.

radeusgd added a commit to radeusgd/graal that referenced this issue Sep 6, 2023
radeusgd added a commit to enso-org/enso that referenced this issue Sep 6, 2023
radeusgd added a commit to radeusgd/graal that referenced this issue Sep 6, 2023
mergify bot pushed a commit to enso-org/enso that referenced this issue Sep 7, 2023
- Closes #7238
- Aligns `update_database_table` to a more consistent and clearer API - `update_rows`.
- Adds a `truncate_table` helper function, to pair up with `drop_table`. Both are `PRIVATE` for now.
- Adds tests for NULLs in keys in `update_rows` and `delete_rows`.
- The behaviour is sometimes unexpected, so instead these fail with `Null_Values_In_Key_Columns`.
- Adds a workaround for oracle/graal#7359
- Adds a workaround for a related bug where a stack frame has no name (its `rootNode.getName() == null`).
- I could not track down this bug to provide a neat repro.
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