TG crashes in auto bph mode with no signal or noisy signal

[colincoleman]

tg-timer consistently crashes if the bph is set to auto and there is no signal or a noisy signal from a ticking watch.

This crash does not happen if a value is selected for bph.

[colincoleman]

I believe I know why this happens... A PR may be on its way very soon...

When BPH is set to "guess" (0) and the watch signal is lost or unsteady, estimate_period() locks onto spurious noise peaks in the autocorrelation data and returns a large bogus period. This period passes the quality gate in compute_update() because count <= 1 yields sigma = 0, which trivially satisfies sigma < period / 10000. The large period then causes Variable-Length Arrays (VLAs) in compute_amplitude() and compute_parameters() to exceed the 544KB computing thread stack, resulting in a SIGBUS crash.

[xyzzy42]

Why do you think the stack size is only 544 kB? That is too small. If that is truly the stack size then I'm not surprised that crashed.

There's already a check for period size being too large that limits it to +20% of the expected value. In auto mode with no detected bph, it uses 12,000 as the bph for the 20% limit. That's a slower speed, but not unusual for an old movement. Is isn't in pendulum clock range. It's possible to manually enter a slower bph, and thus an even longer period.

What is the large period value that causes the crash? It should be a perfectly reasonable period. If it's crashing, then it would impossible to do anything with a slow BPH too. Any patch attempting to address this by considering only auto bph wouldn't fix the underlying problem.

[colincoleman]

The crash was happening (in auto mode) every time I took the watch off the microphone - or started the program without a watch on the microphone. I could also get it to crash if I moved the microphone or added other noise.

I will admit - I used Claude to debug this. The analysis is correct but the reason I am seeing this and perhaps you are not is because I am running on a Mac.

On MacOS pthread_create default stack size is 512kB.
I will update my PR to start each thread with the Linux default of RLIMIT_STACK (8MB on most systems)
I will keep the sigma check in there as it helps avoid unnecessary computation at little cost.

[xyzzy42]

The AI wasn't really correct, since the problem is not the long period, which is limited to a reasonable value for the BPH, the AI totally failed to find that. The real problem is the small default stack size on MacOS. Or perhaps that the intermediate buffers are to large to be appropriate for stack allocation.