Improve error handling in scan_offsets function by replacing panic

[Benkia]

Hi

Its my first contribution here :)

I have an app that run on multiple bin files and I've noticed that when one of the files is corrupted the app exits with

bad header 0x2211 at 18054
bad header 0x1118 at 18055
bad header 0x186c at 18056
bad header 0x6ced at 18057
bad header 0xed50 at 18058
bad header 0x50a3 at 18059
Invalid length in FMT message at 18060

What I've noticed it that the C code dfinex.c is exitsing when it has issue with the header or format
But when I am using "PYMAVLINK_FAST_INDEX=0" and using the python code the behavior is changed and it only print message -

DFFormat: Unsupported format char: '�' in message �M\xa4�

So I've changed the code to print only
Let me know if thats OK or you would want to see something else

[Benkia]

Hey @peterbarker @robertlong13
Kind reminder
Is there anything that I can add to help you understand it?

[robertlong13]

Is there anything that I can add to help you understand it?

No you're good, I've just dropped the ball on reviewing this fully. I'll try to get to it in the next couple days

[robertlong13]

Your right that a panic is going too far. It should be a break so that you can actually still use the log up to the first point of corruption. But it needs to be a break, not a continue.

[robertlong13]

Your right that a panic is going too far. It should be a break so that you can actually still use the log up to the first point of corruption. But it needs to be a break, not a continue.

Suggested change

	i++;
	continue;
	break;

The python code breaks for these failure types, and for good reason. We cannot continue and hope to resync and salvage the rest. There's no fixed marker and no CRC, so the entire chain breaks down if we keep trying after a failure like this. If a single byte gets corrupted, and we'll end up scanning for the next byte that happens to be a valid message id (which is a large percentage of bytes), then we'll jump by the length of that supposed message (i.e., jump by a random value) and end up inside the body of another random message until we maybe get lucky and hit the real head of a message.

Now, the python side doesn't actually have this exact same check (the FMT length check), but the same logic applies, for this and the unknown msg type error. This case is impossible to hit without a byte corruption and we can't keep indexing past this point.

[robertlong13]

Same suggestion as above

Suggested change

	i++;
	continue;
	break;

[Benkia]

@robertlong13 Done

[robertlong13]

Looks good to me. @peterbarker may want you to squash the commits, but the code is good.

[peterbarker]

Merged, thanks!