6x 24hr = 144hr crashfree continuous run and counting..
Tomorrow around this time I will stop it manual if it still did not crash.
A full week of crash free run I would consider "demonstrated".
That will give me at least a "fix/workaround to run my application under TC17".
I will however do a bit more work to zoom-in on rootcause...
I will get the screensaver deactivated by the instructions from @Rich
Than I will restart with select() back in but read() still on non-blocking (the select() will than not have any function but just be there to test whether it hurts).
The difference between original program and currently running version is not only that select() is no longer called, the read() is now called in non-blocking mode in stead of "select() gated blocking mode". So.... rootcause could be select() but it could also be that "blocking read() call" blocks forever even if there is no reason to do so. This would actually connect to the fact that zero logging gets produced at a crash. "The system just locks".
I'm running on a single core cpu. So if this single core gets stuck there is nothing else to take over (not sure it works like that, but it is at least a fact).
Current version of the application is made configurable on this by a user setting so I can run this configuration change without need for recompile. That is a benefit. This brings the amount of changes to an absolute minimum.
So....
- Any advice from a different timezone on "what to do with next run" is welcome.
- Again... although I'm logging rsyslog towards a network connected second computer, I get zero logging from rsyslog with a crash, even though I'm logging at kern.* level. Any advice to get more logging would also be welcome.