There are currently issues where the non-.exe-suffixed files can't be
copied into the `artifacts` folder; `cp` claims "File exists".
Previously this worked but the suffix was added by Cygwin so all files
in `artifacts` had a `.exe` suffix anyway.
This is evidently intended, though non-intuitive, behavior:
https://sourceware.org/legacy-ml/cygwin/2009-08/msg00293.html
> On Cygwin, you should avoid having a file "foo" and a file "foo.exe"
> in the same directory at all cost to avoid puzzeling POSIX borderline
> behaviour like this. What you do is essentially in the "not
> supported" class of problems.
> [...] Cygwin does not check for a file "foo", if the name of the file
> is explicitely given as "foo.exe".
Apparently something similar was addressed in PR #20926; the current
code installs files with both suffixes, but that fix contradicts the
info above and now has broken.
This PR changes the code to only install .exe-suffixed files, as opposed
to only non-.exe-suffixed files, which was the behavior before that PR.
There might be multiple copies of the flags, so remove all of them. Also
pull the setup into a helper function to avoid duplicating the logic.
On ChibiOS boards, this fixes SITL (which had issues with position
quantization) and affects the SBF GPS driver (which was probably fine
before but does change slightly).
We're using a value off the wire before it has been validated. That value is used to limit indexing into a buffer, and that buffer isn't big enough to handle all possible "bad" values that index could take on. Note that "read" here returns int16_t....
the AP_CANManager::log_text() gets called from debug logging in
AP_DroneCAN. It is a method on a common AP_CANManager object which is
shared by multiple AP_DroneCAN threads.
if two threads call the debug log messages at the same time then we
can end up with _log_pos greater than LOG_BUFFER_SIZE (1024) and
overwrite past the end of the buffer
in the crash_dump we have for this case the next piece of memory was
hal.can[0], and the overwrite of the buffer had corrupted the
MessageRam_ structurre in the ChibiOS CAN interface code. That led to
a hardfault on receive of a CAN message
Note that this issue only happens if CAN_LOGLEVEL is set to greater
than zero, and the default is zero. So users can avoid the bug by
checking they have not changed CAN_LOGLEVEL.
Also, this is likely an issue that only happens on startup, as once
the two AP_DroneCAN threads are fully running they have the same
thread priority so can't pre-empt each other. During startup some
messages are sent from the main thread which has a different priority
to the AP_DroneCAN threads, and can thus trigger this issue
