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

JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify #2912

Closed
wants to merge 2 commits into from

Conversation

@MBaesken
Copy link
Member

@MBaesken MBaesken commented Mar 10, 2021

In java/awt/font/TextJustifier.java justify-method there is a potential code path where divison by zero might happen , see also the Sonar finding
https://sonarcloud.io/project/issues?id=shipilev_jdk&open=AXcqMwpm8sPJZZzONu1k&resolved=false&severities=CRITICAL&types=BUG

        boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) == (delta < gslimit)));
        boolean absorbing = hitLimit && absorbweight > 0;
        // predivide delta by weight
        float weightedDelta = delta / weight; // not used if weight == 0

In case of (weight == 0) the division should not be done because the value of weightedDelta is unused in this case anyway.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2912/head:pull/2912
$ git checkout pull/2912

Update a local copy of the PR:
$ git checkout pull/2912
$ git pull https://git.openjdk.java.net/jdk pull/2912/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2912

View PR using the GUI difftool:
$ git pr show -t 2912

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/2912.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Mar 10, 2021

👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Mar 10, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 10, 2021

@MBaesken The following label will be automatically applied to this pull request:

  • 2d

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the 2d label Mar 10, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 10, 2021

Webrevs

@@ -155,7 +155,10 @@
boolean absorbing = hitLimit && absorbweight > 0;

// predivide delta by weight
float weightedDelta = delta / weight; // not used if weight == 0
float weightedDelta = 0;
if (weight != 0) { // not used if weight == 0
Copy link
Contributor

@prsadhuk prsadhuk Mar 10, 2021

Can it ever be -ve? Maybe we can do weight > 0 check just as we do for absorbweight?

Copy link
Member Author

@MBaesken MBaesken Mar 10, 2021

Hi, I am not sure about the weight > 0 check ; weight is initialized with 0: weight = 0; and later some values are potentially added up to weight: weight += gi.weight;
I am not sure about those gi.weight values, maybe they can be negative too ?

Copy link
Contributor

@prrace prrace Mar 10, 2021

Nothing throws an exception or otherwise prevent this being negative but that would be a weird usage. Typically the weight is either zero or based on the font size .. which ought not to be negative but I don't think anything prevents it and I think we would treat it essentially as a transform. So If you really want to be careful here, then yes assume weight could be negative.

Copy link
Contributor

@prsadhuk prsadhuk Mar 11, 2021

By that same logic, then shouldn't absorbweight also be checked as != 0 instead of > 0 as that also uses += gi.weight

Copy link
Member Author

@MBaesken MBaesken Mar 11, 2021

Hi, I am not sure about the absorbweight check; but currently the calculated value weightedAbsorb is only used when absorbing is true. And there the > 0 check is present too

boolean absorbing = hitLimit && absorbweight > 0;

Copy link
Contributor

@prsadhuk prsadhuk Mar 11, 2021

I meant that since we are dividing by weight and absorbweight
weightedDelta = delta / weight;
and
weightedAbsorb = (delta - gslimit) / absorbweight;
where both weight and absorbweight uses += gi.weight values so if one is checking for >0
then to be consistent, in my opinion,
other one should be same or absorbweight also probably should check !=0.

Copy link
Member Author

@MBaesken MBaesken May 4, 2021

should we then better check for
if (weight > 0)
instead of
if (weight != 0)
like it is done for absorbweight ?
(If you think consistency is important here)

Copy link
Contributor

@prsadhuk prsadhuk May 5, 2021

I guess since it was mentioned before that nothing prevents the value from being -ve,
I guess better will be to use != 0 check for absorbweight too?

Copy link
Member Author

@MBaesken MBaesken May 5, 2021

okay, I adjusted the check for absorbweight .

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 21, 2021

@MBaesken This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@openjdk
Copy link

@openjdk openjdk bot commented May 6, 2021

@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:

8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify

Reviewed-by: psadhukhan

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 910 new commits pushed to the master branch:

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label May 6, 2021
@MBaesken
Copy link
Member Author

@MBaesken MBaesken commented May 6, 2021

/integrate

@openjdk openjdk bot closed this May 6, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels May 6, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 6, 2021

@MBaesken Since your change was applied there have been 911 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

Pushed as commit ea30bd6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@MBaesken MBaesken deleted the JDK-8263362 branch May 6, 2021
@MBaesken
Copy link
Member Author

@MBaesken MBaesken commented Aug 31, 2021

/backport jdk11u-dev

@openjdk
Copy link

@openjdk openjdk bot commented Aug 31, 2021

@MBaesken Unknown command backport - for a list of valid commands use /help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants