Question

Should it be possible for this method to return -1?

def tree_value(self, team, x, y):
    if team == NO_TEAM or self.team_sees_tree[team, x, y]:
        return int(self.tree[x, y])
    else:
        return TREE_NONE

Set up:

import numpypy as np

TREE_NONE = 255
NO_TEAM = -1

self.tree= np.empty((dim, dim), np.uint8)
    for i in xrange(dim):
        for j in xrange(dim):
            self.tree[i, j] = TREE_NONE
    self.team_sees_tree = np.zeros((16, dim, dim), np.bool_)

During normal operation, tree values are set to 0-15 (team number) or TREE_NONE (255). Even if they were accidentally set to -1 (NO_TEAM), that should equate to 255 as a uint8.

Call to tree_value() that gets the -1:

data = [(self.Tiles.tree_value(COLOR_NONE, x, y),
    self.Tiles.mountain_value(x, y)) for (x, y) in coords]
str = ""
try:
    for (t, m) in data:
        str += chr(t) + chr(m)
except ValueError as e:
    print data
        # [(255, 0), (255, 0), (255, 0), (255, 0), (255, 0), (-1, 0), (255, 0)]
    print e
        # ValueError: character code not in range(256)

Can't accurately reproduce this problem, but my server is hitting it about twice an hour. Running PyPy recent nightly build (pypy-c-jit-64927-e0ba4acfd3c2-linux.tar.bz2) on Ubuntu 12.04 32bit.

Was it helpful?

Solution

Fixed in PyPy; it was really a bug (see https://bugs.pypy.org/issue1578). The code in one rarely-executed path was forgetting about unsigned integers, and so always reading the byte as a signed value. More precisely, this code was in the JIT tracer. That's why it gave a bogus result only once, with all previous results correct (computed by the interpreter), and all following results correct as well (computed by the assembler that we just generated).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top