C stack overflow: move::burst caught in an endless loop if x and f don't match.
Running what seems to be well-formed objects: one a move
that otherwise works fine, with 1344 features, 3 variables, well-defined time-stamps, etc; and the second an extracted factor variable Day/Night (just like the vignette example of leroy
) with one fewer observations than 1344, so 1343. Running move::burst()
gives an immediate C stack usage limit issue - stack overflow.
When debugging, what seems to be happening is that the generic is just cycling on itself endlessly until it runs out of stack:
Browse[83]>
debugging in: burst(x = x, f = as.factor(f))
debug: {
standardGeneric("burst")
}
Browse[84]>
debug: standardGeneric("burst")
Over, and over. I've verified that the inputs are of class move
and factor
, and the size is correct. Any idea why the function isn't actually executing? The objects are of the expected class ... is something malformed that is breaking the standardGeneric("burst")
?
Update: it's just that the number of locations doesn't match. I wasn't looking at the right object: there's a refactor in the middle, so it's a "code out of order" error. The move
object has n.locs(obj) = 2425
in one instance, and 1344 in the other; there are only 1344 observations in the factor
variable.
Would the function try to auto-reuse the vector and break? I would have expected that this would be a stopifnot()
kind of scan, to prevent a common mistake, but maybe not?
So maybe this is a suggestion for a stopifnot
added to the move::burst()
call to prevent this error: a C stack error
is scary to the user, while a Your burst factor does not have the correct number of locations; check your inputs.
is not.