I had a bug that caused an integer overflow, resulting in wrong (negative) timestamps being written to the database. The code is fixed already, but I want to fix the wrong data, too.
I thought, I could just take the wrong results and add Integer.MAX_VALUE, but that didn't seem to work, it left me with to high values. I have the offset value in the code snippet below, but the input values are not stored.
The following code reproduces the bug:
#Test
public void testArexxConversion()
{
// The input values represent seconds since midnight, Jan 1, 2000 UTC
final int sample = 361450072; // A sample input value drawn from production
// I use the offset from the UNIX epoch to convert the vakue to UNIX seconds
final int offset = 946684800; // midnight, Jan 01 2000 UTC in UNIX seconds
// This was the buggy line in my code, the assertion will fail
long result = (sample + offset) * 1000;
// Prints 'Result is negative: -1830153280'
Assert.assertTrue(result > 0, String.format("Result is negative: %d", result));
// This is for comparison
Date dt = new Date(offset * 1000);
Assert.assertEquals(dt.getTime() + sample * 1000, result);
}
How to fix the bug in your database
To fix the bug in your database you can do the following addition to all the buggy data:
long new_result = old_buggy_result + 1309965025280L;
The constant number was found like this:
Check the buggy result value
Find what should the correct result value be?
Do an addition to the buggy result value to find the correct `result.
But this is only possible if you have saved sample and offset in your database or somewhere else.
Otherwise, it depends on the number of wraps that occured during the original calculation:
long size_of_int = (long)Math.pow(2, 32);
int number_of_wraps = 305 // Only correct in your example!
// You can't deduct the number of wraps from
// the wrong value alone, because that information
// is lost in the modulo (the "wrap")
long correct_number = wrong_number + size_of_int * number_of_wraps;
If the numbers in your database are close enough to your sample value, this means, you can do the above, using 305 as the number of wraps.
Explanation of the bug (for future readers)
The operation here:
(sample + offset) * 1000;
is computed using int and not long. But the result is "too big" to be saved on an int variable. That's why you have an overflow.
Change it to:
((long) sample + offset) * 1000L;
So now the + and * operations will be done using long values, and the result will be a long value which won't overflow.
That would be like this:
long result = ... ; // bad negative from database
long new_result = (long)((int)result - Integer.MAX_VALUE) + Integer.MAX_VALUE;
Replace this line.
long result = (long)(sample + offset) * 1000L;
Related
I am new to java, and I don't understand the differences between these two:
Lets init some variables for the overflow:
byte myByte = 100;
short myShort = 5000 ;
int myInt = 2_000_150_000;
I know whenever I got variable and arithmetic I need to do a casting with (long)
long myLong = (long)(50_000 + 10 * (long)(myByte + myShort + myInt));
long myLong2 =(long)(50_000 + 10 * (myByte + myShort + myInt));
sysout(myLong);
sysout(myLong2);
OUTPUT:
20001601000
-1473235480
but why do I need to do it outside two times?
for short type, this works differently:
short myShortTest = (short)(50_000 + 10*(short)(myByte + myInt +myShort));
short myShortTest2 = (short)(50_000 + 10*(myByte + myInt +myShort));
sysout(myShortTest);
sysout(myShortTest2);
OUTPUT
13800
13800
Whenever an overflow happens, an int will move to the other end of the boundary as seen in the output of the following program:
public class Main {
public static void main(String[] args) {
System.out.println(Integer.MAX_VALUE);
System.out.println(Integer.MAX_VALUE + 1);
System.out.println(Integer.MIN_VALUE);
System.out.println(Integer.MIN_VALUE - 1);
}
}
Output:
2147483647
-2147483648
-2147483648
2147483647
In the case of test1, because of casting to long, the result of the intermediate calculation [10*(long)(myByte + myShort + myInt)] was stored as long which can accommodate the result without an overflow and hence you got the correct value.
In the case of test2, in lack of proper cast, the result of the intermediate calculation [10*(myByte + myShort + myInt)] was stored as int but the value overflew for int and hence you got the negative value.
Your first version reads: add up my variables, treat the result as a long, multiply by 10, add 50000 and treat that as a long.
Your second version reads: add up my variables (result is an int), multiply by 10 (which is still an int but might be overflown), add 50000 (still a possibly overflown int) and treat that as a long.
So your fist version starts to treat the sum as a long value and reserves sufficient memory while your second version does this step at the very end, working with lower memory until then.
I encountered a troublesome issue and I can't really explain to myself why it is appearing.
Basically I want to add time to a timestamp (a simple long).
I understand it the following. If I add time to a timestamp I end in the future. If I subtract time to the timestamp I end in the past.
In my example it is the other way around. If I add something to my timestamp it is reduced and if I subtract something is added.
public class MyClass {
public static void main(String args[]) {
static final int MONTH_IN_SECONDS = 2629743;
final long current = System.currentTimeMillis();
System.out.println("Current: " + current);
final long future = System.currentTimeMillis() + (MONTH_IN_SECONDS * 1000 * 3);
System.out.println("Addition: " + future);
final long past = System.currentTimeMillis() - (MONTH_IN_SECONDS * 1000 * 3);
System.out.println("Subtraction: " + past);
}
}
Result (compare the first 5 chars):
Current: 1582275101365
Addition: 1581574395774 // smaller than current even though it should be greater
Subtraction: 1582975806958 // great than current even though it should be smaller
Why does this happend? Does the term (MONTH_IN_SECONDS * 1000 * 3) overflow because it is only an Integer and thus the calculation does not work (or ends in a negative value)?
If I change the term to (MONTH_IN_SECONDS * 1000L * 3) it seems to work correctly. Is it because the complete term is casted to a long?
The problem is here:
(MONTH_IN_SECONDS * 1000 * 3)
That's integer multiplication that's overflowing, and resulting in a negative number:
System.out.println((MONTH_IN_SECONDS * 1000 * 3));
That outputs -700705592. You'd have to declare MONTH_IN_SECONDS as long, or otherwise change the expression so that the result is long-typed.
Does the term (MONTH_IN_SECONDS * 1000 * 3) overflow because it is
only an Integer and thus the calculation does not work (or ends in a
negative value)?
Month in seconds? Google says 2,630,000. (Though I see you have 2629743.)
2,630,000 * 1000 * 3 = 7,890,000,000
Integer.MAX_VALUE = 2^31 = 2,147,483,648
So yeah, it's an integer overflow.
I just stepped onto problem with generating id for notification in Android.
I'm going through some notification-handling-sdk and they are using this code to generate notification id:
private int generateTimestampId() {
return (int)(new Date().getTime() % 2147483647L);
}
This is probably good solution, but I can't understand what % 2147483647L stands for in context of epoch time.
(please note: new Date().getTime() returns the number of milliseconds since January 1, 1970, 00:00:00 GMT)
It could be done to prevent negative values which will happen when long is narrowed to int. Consider the following code:
long value = 1L + Integer.MAX_VALUE; // anything past max integer
int i1 = (int) value; // -2147483648
int i2 = (int) (value % 2147483647L); // 1
With the % 2147483647L the code ensures that the number will always be smaller than Integer.MAX_VALUE, which is 2147483647, before it will get narrowed to int.
It more or less makes sense in context of generated ids, we rarely use negative numbers for this use case.
i want to make a simple progressbar showing me how much time some process takes. At the moment of creation of it I have only actual percentage (as int) and time that is left(as String formatted HH:mm:ss). I want it to update every second and show me the actual state of process. I've tried everything and it doesn't work. Current version looks like this - tell me please what I'm doing wrong...
int initialProgress = 35; // %
// time to finish process
Date endDate = new SimpleDateFormat("HH:mm:ss").parse("07:07:07");
Date now = new Date();
long totalDuration = (long) (((double)(endDate.getTimeInMillis()
- now.getTimeInMillis()) * 100.0 / (double)initialProgress);
and then every second I repeat:
now = new Date();
int currentProgress = (totalDuration - endDate.getTimeInMillis()
+ now.getTimeInMillis())/totalDuration;
It simply is not working. Total duration is even something strange...
The issue seems to be that you have a time remaining String and you want to parse it to percentage of work done.
The first thing you need, obviously, is the total expected time. Lets assume that this is also a String.
First write a method for parsing your HH:mm:ss String to a long representing time remaining in seconds.
public long parseToSeconds(final String duration) throws ParseException {
final MessageFormat durationFormat = new MessageFormat("{0,number,#}:{1,number,#}:{2,number,#}");
final Object[] parsedTimeRemaining = durationFormat.parse(duration);
final long totalDuration = TimeUnit.HOURS.toSeconds((Long) parsedTimeRemaining[0])
+ TimeUnit.MINUTES.toSeconds((Long) parsedTimeRemaining[1])
+ (Long) parsedTimeRemaining[2];
return totalDuration;
}
What we do here is use a MessageFormat to parse your String into an array of Object. As we have told the MessageFormat that these are numbers, it will automagically convert (or try to convert, hence the exception) to Long.
Once we have those numbers we scale them all to seconds using the (very useful) TimeUnit class.
A couple of quick tests to ensure we're on the right track:
System.out.println(parseToSeconds("00:00:01"));
System.out.println(parseToSeconds("00:01:00"));
System.out.println(parseToSeconds("01:00:00"));
System.out.println(parseToSeconds("01:01:01"));
Output:
1
60
3600
3661
Looks good.
Lets assume that right as the start of the process we get a time remaining, for simplicity, of "04:04:04", this gives 14644. Now we just need to store that and calculate the percentage against any new duration String. This should do the trick:
public int asPercentage(final long totalTime, final long remaining) {
final double percentage = remaining / ((double) totalTime);
return (int) (percentage * 100);
}
Note the fact that I cast (seemingly pointlessly) one of the items to a double. This is because in Java any operation on an integral type always returns another integral type. Casting to a double forces it to return a double.
Lets do a quick check again:
final long totalDuration = 14644;
System.out.println(asPercentage(totalDuration, parseToSeconds("03:03:03")));
System.out.println(asPercentage(totalDuration, parseToSeconds("02:02:02")));
System.out.println(asPercentage(totalDuration, parseToSeconds("01:01:01")));
Output:
75
50
25
Looks good, that is the time remaining as a percentage of the total. Maybe to quite what we want for a progress bar. Lets invert it:
public static int asPercentage(final long totalTime, final long remaining) {
final double percentage = remaining / ((double) totalTime);
return 100 - (int) (percentage * 100);
}
Output:
25
50
75
Ah-ha. Much better.
I want to use milliseconds to set a new date in my program,but it doesnt work. Is there anybody can tell me why it doesnt work?
Calendar r_1 = new GregorianCalendar(2011,0,1);
r_1.add(Calendar.DAY_OF_MONTH,2);
System.out.println(r_1.getTime());
long date_1 = r_1.getTimeInMillis() + 2*24*60*60*1000;
r_1.setTimeInMillis(startTime1);
System.out.println(r_1.getTime());
It works both very correct , but if i change the day from 2 to 25,then it doenst work .
----------the output is correct ,it is 2011/01/26 ----------
Calendar r_1 = new GregorianCalendar(2011,0,1);
r_1.add(Calendar.DAY_OF_MONTH,25);
System.out.println(r_1.getTime());
-----------the output is incorrect now ,it is 2010/12/07------
long date_1 = r_1.getTimeInMillis() + 25*24*60*60*1000;//i have change 2 to 25
r_1.setTimeInMillis(startTime1);
System.out.println(r_1.getTime());
Thanks
The expression 25*24*60*60*1000 is an integer, and you have overflowed the size of an integer, creating a negative number.
Your expression is 2,160,000,000 milliseconds. The largest value an int can hold is 2,147,483,647.
To fix this, you have to force the expression to be a long, as follows
25L*24*60*60*1000
25*24*60*60*1000 is too large to fit in an int.
Try 25L*24*60*60*1000 which is a long constant.
Try something like that:
final long k = 25*24*60*60*1000L;
long date_1 = r_1.getTimeInMillis() + k;