chSysIntegrityCheckI()

[steved]

I've been using chSysIntegrityCheckI() to try and track down registry corruption. It's highlighted that the routine may never return if the linked lists are corrupted in certain ways. Two issues I've found may be detectable:
1. Some types of memory corruption result in invalid memory addresses; attempting to access these causes an exception (which makes it trickier to sort out where the routine was called from). Validation of as many memory addresses as possible prior to use would trap this in a more orderly manner. Certainly a zero address could be caught (at least on ST devices), and some range checking should be possible.

2. If the 'next' pointer is perceived to be zero, then you can get an infinite loop.

[Giovanni]

It would require a "address validator" macro for pointers but that would be architecture-specific, it is something that should be added to the port layer.

A perfect check would require the pointers to fall into a valid RAM area but that would require knowledge of all valid ranges, some could be on external devices and of unknown size. A possible solution would be to use a macro that could be overridden by the user.

Giovanni

[steved]

Might it be possible to automatically derive the info for an address validator from the scatter files? Considering only chSysIntegrityCheckI(), addresses must be in RAM, and either within the heap/memory pool area or within a limited number of RW areas. A more generic validator could have flags to indicate whether RO and/or RW memory is acceptable.

An overridable macro or function might be the simple solution.

The infinite loop problem could be solved simply by limiting the number of steps permitted in the linked list to an improbably large number - 1000 threads, maybe?