-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8346881: [ubsan] logSelection.cpp:154:24 / logSelectionList.cpp:72:94 : runtime error: applying non-zero offset 1 to null pointer #22903
Conversation
👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into |
@MBaesken This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 6 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
|
||
if (comma_pos == nullptr) { | ||
break; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this check is not necessary here since it is checked in the for loop condition already - or am I overlooking something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we still run into the issue , even with the existing loop condition.
check the flowchart of the for loop
https://www.programiz.com/cpp-programming/for-loop
the update condition is done after the body ; then we run into the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right, I see. But in that case, we can/should remove the check for comma_pos != nullptr from the condition because we're explicitly doing it in the loop body then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, the check can be simplified .
Seems we have a similar one here, show by test runtime/MemberName/MemberNameLeak (macOS aarch64)
Should I address it here too ? |
yes, makes sense. |
I adjusted logDecorators.cpp too . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for the sake of consistency, the loop in logSelectionList.cpp could be transformed into a do {} while(), like in the other two locations, but in any case, the change looks good to me as it is now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Thanks for the reviews ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM2
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I think char* token = args_copy;
char* comma_pos; these two variables are doing no good by being in function scope. If it would have been a for loop then then would exist in the loop's scope only. As that's the case for for (char *comma_pos = copy, *cur = copy; success; cur = comma_pos + 1) { It might not be a big deal but still I find later one appropriate :-) |
Thanks for the reviews ! /integrate |
Going to push as commit 0a81676.
Your commit was automatically rebased without conflicts. |
When running jtreg tests on macOS aarch64 with ubsanized binaries, the following error is reported :
(XCode 13.1 was used)
This can be seen e.g. in these jdk jtreg tests :
jdk/internal/misc/CDS/ArchivedEnumTest.java
jdk/jfr/event/gc/collection/TestGCGarbageCollectionEvent.java
jdk/jfr/startupargs/TestDumpOnExit.java
There is another issue observed here (also when running on macOS aarch64) , seems this happens in the for loop when incrementing comma_pos
" for (char *comma_pos = copy, *cur = copy; success && comma_pos != nullptr; cur = comma_pos + 1) { ..."
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22903/head:pull/22903
$ git checkout pull/22903
Update a local copy of the PR:
$ git checkout pull/22903
$ git pull https://git.openjdk.org/jdk.git pull/22903/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22903
View PR using the GUI difftool:
$ git pr show -t 22903
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22903.diff
Using Webrev
Link to Webrev Comment