Spent yesterday morning working on filing. The dates for my paintings, events, films, were stored in Dec 1 (2010) format - or others. I changed all to 1 Dec (2021) for example. The paintings file is 37,000 lines, so this process took several hours.
Then I created some music. Prometheus crashed again when clicking Stop, an old bug which is so rare it's very difficult to track down. It may be several different bugs, or a memory infringement which occurs earlier, and later causes the crash. At one point I tracked it to between waiting for the play thread to finish, and the end of it, somewhere between [A] and [B] here:
[A]
// Wait for thread to finish
if (waitforthreadtofinish)
while (inplaythread)
Sleep(1);
[B]
inplaythread is active when the player thread is running and set to zero at the end (it will reach the end at the end of its loop once then set inplaythread=0). Now, the crash could be in the player thread or caused by something after it, but I thought it was odd that normal playing is very stable. The crash only appears during stop. I wondered if the Sleep(1) was a culprit. Of course, 1 millisecond is very short... perhaps too short anyway. I thought that Sleep was a Windows API function, but it seems to be a C command. This might be the only time I've ever used it...
So I've replaced it with something which waits for 50 millisecs using the certainly stable timeGetTime()
// Wait for 50 millisecs
void waitforafewmillisecs(void)
{
lword t;
for (t=timeGetTime()+50; t>timeGetTime(); );
}
Perhaps it is a forlorn hope to blame Sleep. On the next crash I will take steps to add tracers. This is the longest term and most strange of Prometheus bugs.
