Re: Anyone else seen Heisenbugs?

I can't say I have, except in those cases where I reorganized code using 
environment variables: because environment variables retain their values 
across control-period, the code can seemingly remain working while it is 
silently broken (e.g. accessing a variable before it is assigned).

Another possibility that comes to mind is a lost OSC message (but your 
problem sounds more like something language side than server side).

Having said this, given your level of experience, it's probably not what 
you were facing.

When I start scide under valgrind, I'm kind of surprised how many 
problems it sees even during startup of the system: some in Qt5 or other 
system libraries libraries, but also several supercollider specific c++ 
class members seem to remain uninitialized in the constructor, while 
their values are already checked before they are assigned something 
(meaning they can have random values, especially in release mode) which 
is a good ingredient to create Heisenbugs.

It would be interesting to try and clean up some of these problems, even 
if they probably won't solve your specific problem in the short term.

On 3/29/20 5:30 AM, [email protected] wrote:
> Has anyone else seen this sort of Heisenbug?
>
> Something like this happens to me every so often... something is not
> behaving correctly, and I put in debugging posts, and... immediately
> (without any logic or data changes that I can identify), the problem
> disappears. And then, after removing the debugging posts, the problem
> is no longer reproducible.
>
> Yesterday I was debugging a breakbeat process -- it was playing the
> buffer at the wrong rate. Rate is calculated from tempo / loopTempo,
> loopTempo = sample rate / samples in a beat (provided by the user),
> times clock tempo. Calculating it by hand, it should have been:
>
> loopTempo = 44100 / 35004 = 1.259856
> tempo = 111.7/60 = 1.8616667
> rate = 1.8616667 / 1.259856 = 1.477682
>
> But... when I started yesterday, I was getting `"rate", 1.13952` in
> OSC messages, and the sound was completely wrong (playing in triplets
> rather than 16ths, and the barlines didn't match).
>
> The numbers going into the calculation seemed to be correct (the
> process object had 35004 in the right place), but the result was
> definitely wrong.
>
> Then, it magically resolved by printing out the numbers in the middle
> of the calculation.
>
> I had checked git diffs to see if I changed anything else accidentally
> when adding the print statements... nothing.
>
> I find this disturbing. To get a radically different result from a
> calculation should require changing the input numbers.
>
> Unfortunately, this is not the only time this has happened. I can
> recall multiple, mysterious instances like this over the years (which
> are exceptionally difficult to document, because the problem
> disappears the moment you start to gather evidence)... where I'm 100%
> it was behaving incorrectly, and I spent up to a couple of hours
> trying to track down the failure... and then it magically stopped
> happening.
>
> One possible explanation could be a subtle interpreter glitch -- if,
> under some rare circumstances, it accesses a wrong memory location.
> I'm speculating. All of this is extremely weird.
>
> hjh
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/