Bug in loop handling code when multiple loops are present
jonathancrabtree opened this issue · 1 comments
There's a fairly subtle loop handling bug that only occurs when:
- A configuration file contains multiple loop constructs
- One of the loops that isn't the first makes use of label or color functions
- The track hashref keys are enumerated in a particular order (i.e., it's Perl version/implementation/platform dependent)
The issue has to do with the fact that the "original_fn" prefix is used to preserve function symbolic names for later evaluation (later meaning when the loops are unrolled.) In some cases the preservation code is mistakenly applied twice, resulting in keys with the prefix "original_fn_original_fn". Depending on whether the restoration code sees "orginal_fn_X" or "original_fn_original_fn_X" first, the function can fail to be restored correctly and the function that ends up getting run can be one that doesn't have the correct (or rather, any) binding for the proximate loop variable. The fix should be easy, but there's no easy way to check for all possible key enumeration orders. It may make sense to force a key enumeration order that always exposes the bug, at least for testing purposes.