-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(chainbase): guard divide-by-zero #6687
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
Changes from all commits
1f3931f
0498357
58798e9
96347b2
671fc07
56fcea7
f7c7252
42a3345
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -295,13 +295,14 @@ private void resetAccountUsage(AccountCapsule accountCap, | |
| } | ||
| long currentSize = accountCap.getWindowSize(ENERGY); | ||
| long currentUsage = accountCap.getEnergyUsage(); | ||
| // Drop the pre consumed frozen energy | ||
| // Drop the previously consumed frozen energy | ||
| long newArea = currentUsage * currentSize | ||
| - (mergedUsage * mergedSize - usage * size); | ||
| // If area merging happened during suicide, use the current window size | ||
| long newSize = mergedSize == currentSize ? size : currentSize; | ||
| // Calc new usage by fixed x-axes | ||
| long newUsage = max(0, newArea / newSize, dynamicPropertiesStore.disableJavaLangMath()); | ||
| // A zero window size means no valid time window exists and thus zero usage | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [NIT] New comment removes the algorithm context from 'fixed x-axes' The original comment The same applies to the equivalent line in Suggestion: Merge both meanings, e.g. // Calculate new usage from area/window model; zero window means no valid time context and yields zero usage |
||
| long newUsage = | ||
| newSize == 0 ? 0 : max(0, newArea / newSize, dynamicPropertiesStore.disableJavaLangMath()); | ||
| // Reset account usage and window size | ||
| accountCap.setEnergyUsage(newUsage); | ||
| accountCap.setNewWindowSize(ENERGY, newUsage == 0 ? 0L : newSize); | ||
|
|
@@ -312,13 +313,14 @@ private void resetAccountUsageV2(AccountCapsule accountCap, | |
| long currentSize = accountCap.getWindowSize(ENERGY); | ||
| long currentSize2 = accountCap.getWindowSizeV2(ENERGY); | ||
| long currentUsage = accountCap.getEnergyUsage(); | ||
| // Drop the pre consumed frozen energy | ||
| // Drop the previously consumed frozen energy | ||
| long newArea = currentUsage * currentSize - (mergedUsage * mergedSize - usage * size); | ||
| // If area merging happened during suicide, use the current window size | ||
| long newSize = mergedSize == currentSize ? size : currentSize; | ||
| long newSize2 = mergedSize == currentSize ? size2 : currentSize2; | ||
| // Calc new usage by fixed x-axes | ||
| long newUsage = max(0, newArea / newSize, dynamicPropertiesStore.disableJavaLangMath()); | ||
| // A zero window size means no valid time window exists and thus zero usage | ||
| long newUsage = | ||
| newSize == 0 ? 0 : max(0, newArea / newSize, dynamicPropertiesStore.disableJavaLangMath()); | ||
| // Reset account usage and window size | ||
| accountCap.setEnergyUsage(newUsage); | ||
| accountCap.setNewWindowSizeV2(ENERGY, newUsage == 0 ? 0L : newSize2); | ||
|
|
||
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.
[QUESTION]
newAreastill relies on rawlongmultiplications/subtractions here. I realize this is pre-existing code rather than introduced by this PR, but since this method is already being touched for numeric safety, do we want a follow-up to harden these arithmetic operations with the existing exact-helper pattern as well?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.
Good observation. While there's a theoretical overflow risk in
newArea = currentUsage * currentSize - (mergedUsage * mergedSize - usage * size), in practice this won't occur in java-tron's business context — bothcurrentUsage (energy usage)andcurrentSize (window size, capped at WINDOW_SIZE_MS / BLOCK_PRODUCED_INTERVAL = 28800)are tightly bounded by the protocol's energy limits, so the product stays well within long range. But I agree it's worth noting as a pre-existing pattern; happy to track it in afollow-up if you'd like.