Um... A forced reboot shouldn't increment that number. Those are things like installation failures and management errors (like when you start something that needs sig patches) Did you simply force poweroff 9 times recently to bump up that number to 807, or did you try some installs or intentionally crash something? The reasons for the failures are noted in /storage_slc/logs.
Anyway, losing a console to a storage or system failure during writing is bad luck, but it can happen. Losing two makes you go hmmm... (But you still can't use bad numbers to make a good point.)
Oh, they aren't bad numbers. The reason it changed was because I initially went with the highest numbered log in /vol/storage_slc/logs (99.log) but I later realized that the counter wraps around; so I updated it with the actual number from the latest log (8.log). While your point about a forced reboot not incrementing that number is correct; you didn't see the context - I'm a homebrew developer. The vast majority (I'd even wager all) of the fatal errors on my system are a result of homebrew code that's in development or whatever. When this occurs, the error falls through to MCP (thanks OSFatal) and the console locks up, requiring me to force a shutdown by holding the power button. There are few, if any, other situations where a
fatal error would be logged - installation issues and sigpatches pop up an error, but the console continues to operate. These, therefore, are not fatal errors and should not contribute to the counter.
This means that the number of fatal errors recorded by MCP is a pretty good indicator of how many times the console has crashed and thus been force restarted. Remeber we're talking
fatal errors here - by definition, the console must crash when one occurs.
For a bit of fun, here's a recent crash log off my system -
7.log (8 was a boring FSGetMountSourceFailed, which required a force reboot nonetheless). My current project sets up some code in the 0x60000000 area and you can see that's where the problem lied. A more recognizable log comes in the form of
98.log; where you can see a more standard homebrew exception handler gets in and causes the panic (again, thanks OSFatal). Every time something like that happens a force reboot is needed.
