WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Re: Tiny Core v17.0 upgrade issues  (Read 6038 times)

Offline Stefann

  • Wiki Author
  • Full Member
  • *****
  • Posts: 168
Re: Tiny Core v17.0 upgrade issues
« Reply #90 on: April 26, 2026, 02:14:36 AM »
small update:
- still running after 48 hour.

This is the first time I have more than 34 hours "full functional on TC17".
- on the one hand this is a stromg indication that select() is the root cause
- on the other hand "not using select() and doing nonblocking read" is a perfect fix for my application

I keep it running for 7 days, until next Friday. If it did not crash by than I call it "demonstrated OS/kext rootcause" and "demonstrated application fix/workaround".

So: No posts on this thread for coming 5 days unless there is a crash.

Offline Stefann

  • Wiki Author
  • Full Member
  • *****
  • Posts: 168
Re: Tiny Core v17.0 upgrade issues
« Reply #91 on: April 27, 2026, 03:30:27 AM »
3x 24hr = 72hr crashfree continuous run and counting..

Offline Stefann

  • Wiki Author
  • Full Member
  • *****
  • Posts: 168
Re: Tiny Core v17.0 upgrade issues
« Reply #92 on: April 28, 2026, 02:21:59 AM »
4x 24hr = 96hr crashfree continuous run and counting..

Offline Stefann

  • Wiki Author
  • Full Member
  • *****
  • Posts: 168
Re: Tiny Core v17.0 upgrade issues
« Reply #93 on: April 29, 2026, 02:15:25 AM »
5x 24hr = 120hr crashfree continuous run and counting..

Offline Stefann

  • Wiki Author
  • Full Member
  • *****
  • Posts: 168
Re: Tiny Core v17.0 upgrade issues
« Reply #94 on: Today at 03:12:04 AM »
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.