3

My friend and I have made a tetris-like game in Java and it works fine for a while and then suddenly bugs out at around the same number of total pieces every time. For example, it might bug out at 42 pieces one time, 46 the next, and 44 the time after that.

[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][2][2][ ][ ][ ][ ][ ][ ][7]
[ ][2][2][2][3][3][ ][4][ ][7]
[2][2][1][3][3][1][ ][4][ ][7]

The above is an example of what it looks like right before the bug happens. Don't try to read into the above sample too much as the bug is not dependent on piece positions, etc.

Here is what the grid looks like right after the bug occurs...

[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][2][ ][ ][ ][ ][ ][ ]
[ ][2][2][ ][ ][ ][ ][ ][ ][7]
[ ][2][2][2][3][3][ ][4][ ][7]
[2][2][1][3][3][1][ ][4][ ][7]

Notice the twos going all the way up to the top of the grid? That is what is happening.

Here's where things get interesting. We have limited it down to a specific function and a specific line of code.

grid[x+legend[piece.type].fetch(i, 0, piece.rotate)]
    [y+legend[piece.type].fetch(i, 1, piece.rotate)]
    .type = piece.type+1;

The above line of code is the exact line of code believed to be causing the problem. The problem is that there is nothing wrong with that line of code. I've been debugging the whole program for about a week and I have it log the grid after every single change.

The difference between the two grids above was one call to that line. It should not be possible for it to have assigned all the other cells in the grid. The debug log said the variables were:

i: 0
legend[piece.type].block.length: 4
legend[piece.type].fetch(i, 0, piece.rotate): 0
legend[piece.type].fetch(i, 1, piece.rotate): 0
piece.type: 1
piece.rotate: 3
x: 3
y: 6

Those were the variables that influenced the second grid above. The buggy line of code would have read:

grid[3+0][6+0].type = 1+1;

Is it possible that we uncovered a bug in Java itself? I've spent hours debugging this code and I've never had a bug I couldn't find (I usually code in python, though... Java is fairly new to me)

Also, it seems that the bug is influenced by the size of the grid. If I set the height of the grid to a lower number, it takes less pieces to cause the bug. On the same token, it requires more pieces if I make a taller grid.

Hopefully the Java experts out there can help shed some light on the situation.

p.s. I'm programming in Eclipse on a Mac using JRE JVM 1.6. I also tried JRE JVM 1.4 and the same thing happens.

Additional info:

private Grid grid[][] = new Grid[dimx][dimy];

the above code is when the grid is created. Grid is a class:

public class Grid {
    int type;

    public Grid(int type) {
    }
}

Here is part of the extensive debug log code... This is the function that prints the text-based grid.

public void printGrid(int line) {
    System.out.print("\n\n\n"+line+":\n");
    for (int y = 0;y < grid[0].length;y++) {
        for (int x = 0;x < grid.length;x++) {
            if (grid[x][y].type == 0) {
                System.out.print("[ ]");
            } else {
                System.out.print("["+grid[x][y].type+"]");
            }

        }
        System.out.println();
    }
    System.out.println("\n\n");
}

The variable 'line' is not important and merely tells us what line number the function printGrid() was called from.

Let me know if you guys need any more information.

More Additional Info:

Here are all the files for this program.

Oh, and here is an excerpt from a debug log to give you more info.

http://pastebin.com/9VKhF8CR

It includes placing a piece successfully (the last piece placed before the bug) and then it shows the bug happening. All the variables for the function are printed and none appear out of place. The bug happens to any piece being placed at any spot on the grid. The grid was printed after each call to the line I talked about above. Let me know if you guys need any more info. I want this bug squashed.

Bandit
  • 143
  • 5
  • 6
    "Is it possible that we uncovered a bug in Java itself?" - unlikely. Always suspect your own code first.... – Mitch Wheat May 19 '11 at 01:48
  • Any message ? NullPointerException or something like that ? IMHO Log file is usefull when you know the code that produced it. – Luc M May 19 '11 at 01:52
  • I'd suggest looking elsewhere for the problem. ("When you have eliminated the impossible, whatever remains, however improbable, must be the truth.") Can you show us the code used to create `grid` and the code that prints it? – Ted Hopp May 19 '11 at 02:27
  • @Ted I have edited in the requested information to my original post. Oh, and the only problem with your quote "...eliminated the impossible, whatever remains..." is the fact that nothing else is writing to the grid when the bugs occur. The grid is only written to when a new piece is being placed and when a row is completed (all the pieces above the row shift down one). The bug is happening when a new piece is being placed, but only after so many total pieces have already been placed. After the bug happens once, it keeps happening (randomly) until I close out and reopen the game. – Bandit May 19 '11 at 19:59
  • From the example you posted, it looks like it's happening when one column gets four items. Can you confirm one way or the other? – Ted Hopp May 19 '11 at 20:44
  • @Ted The bug is not restricted to four items in a column. As far as I can tell, the bug is completely random in that respect. However, it **always** "shoots" up to the top of the grid, never anything else. Also, there seems to be a correlation between the bug and the total number of pieces (in a range of about 10 pieces). There is also a correlation between the bug and the size of the grid. A bigger grid causes the bug to happen later in the game. A smaller grid is the opposite. Getting the bug + hitting "g" (new game) will cause the bug to happen early in the next game. – Bandit May 19 '11 at 22:04

1 Answers1

4

From the description of your problem, it appears as though grid[0], grid[1] through grid[6] are all references to the same row array (but grid[7] and beyond are references to different arrays). This would cause the symptom you describe, where changing a single element causes it to appear to change in all those rows.

Try:

System.err.println(grid[0] == grid[1]);

and see whether you get true or false. You'll probably get true.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • This is a great hypothesis, and I'm voting it up even if it turns out its not the root cause. – Amir Afghani May 19 '11 at 02:03
  • I added the above code to my program and it is logging false. I would also like to reiterate the fact that this only happens **after a while**. The bug does not happen instantly and it takes a while for the bug to kick in. I will keep searching and let you guys know if I make any new discoveries. – Bandit May 19 '11 at 19:18
  • The "after a while" part is meaningless to us, since you haven't shown your whole code, just the end result. All we can do is examine what you've described and come up with ideas for why that has happened. How your data structure got that way is not part of your question. But I can assure you that data structures in Java don't just randomly change on you after a while without you actually doing something to cause that. – Greg Hewgill May 19 '11 at 19:46
  • @Bandit: I suspect the problem is here: `grid[x][yRow] = grid[x][yRow-1];`. Since each element of `grid` is itself a `Grid` object, that assignment will make the two cells `grid[x][yRow]` and `grid[x][yRow-1]` point to the *same* `Grid` object. When you change the contents of that `Grid` object, both cells will appear to change. Since your `Grid` object only contains a public integer field, I suggest changing the `grid` declaration and initialisation to `private int grid[][] = new int[dimx][dimy];`, so the assignment semantics will be what you need (scalar copy instead of reference copy). – Greg Hewgill May 19 '11 at 23:03
  • 1
    An alternate, simpler solution might be `grid[x][yRow].type = grid[x][yRow-1].type;` if you want to stick with using the `Grid` class. – Greg Hewgill May 19 '11 at 23:14
  • @Greg You're a genius. That did the trick. Thank you so much for your help... and everybody else's help as well. You guys are the best. – Bandit May 20 '11 at 01:49