So it’s just happened again… some calculations (this time for a buffer playback rate, but it could be anything) give the wrong value, and when I add some debugging statements and re-create the objects, then the problem goes away.
The debugging statements didn’t change the form of the calculation. But, after adding the debugging statements, the result of the calculation is different. This means that the form of the calculation was always fine, but sometimes the result is incorrect.
And, after reverting to the original code, the problem doesn’t recur. This means that the original code was always fine, but sometimes the result is incorrect.
The most likely explanation is that some expression feeding into the calculation is accessing the wrong slot.
It’s unpredictable when this will happen, or for which value, or for which section of code. And, unfortunately for troubleshooting, efforts to pin down the problem end up destroying the problem.
I’d forget it if it had been once or twice in the 20 years I’ve been using SC. Probably 3-5 times a year, or more: I get some weird value somewhere that seems to have nothing to do with what is actually in the code or data structures, and then it just magically goes away. And then I wonder if I was ever seeing the weird behavior at all (but, if I weren’t seeing weird behavior, then why would I have spent any time at all debugging?).
I’m quite sure I’m not imagining this…
hjh
Have you considered doing a memtest and some CPU test? I.e. is it possible it’s a hardware problem causing incorrect results?
James, are you on Windows or Mac? I have had this happen to me on mac over the last two or three years. It feels like my computer is gaslighting me.
Sam
Hm, that’s worth ruling out. I did have one computer that arrived with a bad memory chip. The symptom was random app crashes. Here, I was getting incorrect – but validly-formed – floats.
Also I’ve experienced this on multiple machines, and only in SC. A hardware problem would affect every app (I’d see wrong values in grading spreadsheets, for instance).
Linux, for a good 10 years now.
That’s exactly what it’s like!
Well, I’m not exactly glad I’m not the only one, but at least I’m a bit more confident that I’m not imagining it.
hjh
One new finding:
(wrong playback rate / correct rate) ~= bar duration of a different breakbeat / bar duration of the correct breakbeat
So the wrong number wasn’t random – it came from a different object.
That suggests not a hardware problem, but an object corruption problem. Whether it’s my bug or SC’s bug, I can’t tell now. I haven’t been able to reproduce the wrong behavior – so it isn’t a simple bug in my codebase.
Will hammer at it again later in the week.
hjh
1 Like
Closing the loop on this: I did finally find a concrete cause for the wrong rate in the breakbeat player.
In chucklib, I use a class BPStream as a kind of pattern proxy that lives in a BP’s environment. For it to work correctly, the BPStream object needs to be created within that environment. I was accidentally creating it within the environment belonging to the process factory. So if I instantiated rhe breakbeat process once using one sample, it would accidentally corrupt the factory. Then the next instance to be created, using a different sample, would refer to the loopTempo of the first sample to be used.
Fixed by writing Plazy { BPStream(\loopTempo) } instead.
That puts my mind at ease actually. I would rather it be my fault than a mysterious GC bug.
hjh