Heisenbug... what to do?

[email protected] Wed, 15 Jan 2020 17:31:18 +0800
Newsgroups gmane.comp.audio.supercollider.devel
Message-ID <CAFniQ7VptQmO=+X=pNykCkizEUs3_heSJq5_thHcYW4SvgryWA@mail.gmail.com>
I've got a case now where the code works when I include debugging
posts, but doesn't work when I remove them. This, of course, makes
troubleshooting difficult because I don't have any visibility into
what's going wrong. (The presence of an observer alters the system
being observed.)

Backstory: I found a race condition in the newly-added MeterSync
class. Since it's fresh in my mind, I wanted to test an approach that
might resolve it -- each sclang instance keeps a list of MeterSync
IDs, in order of creation, and any new MeterSyncs to join the network
will sync up with the oldest responding MeterSync instance. (If the
oldest one drops off the network, then it will stop responding and the
"oldest responding instance" would be the second one that was created,
and so on.)

https://github.com/jamshark70/supercollider/commit/0a90851263bb56f106a263e51f74b31f530b01e4

It looks like, if I comment out the debugging posts in this commit,
the IDs get out of order and the instances sync to the wrong clock.

But... why? Maybe posting causes the timing of outgoing OSC messages
to be just slightly different (which might affect the order in which
messages arrive at other clients)? And how to prove it, if it only
happens when it's not being watched?

I'm a bit stuck here.

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/