This functionality was approximately never used when it existed as an
`@SYS` file, and has been a source of dangerous bugs.
Remove it completely to avoid future problems and save the flash.
The parameter must stay to control handling of `LogMessage` from
peripherals, which were always sent to the GCS.
This functionality was approximately never used when it existed as an
`@SYS` file, so compile it out so it does not suddenly appear.
The parameter must stay to control handling of `LogMessage` from
peripherals, which were always sent to the GCS.
Replace the in-memory _log_buf with GCS_SEND_TEXT, mapping LogLevel
to MAV_SEVERITY. Drop log_retrieve() and the LOG_BUFFER_SIZE buffer
that backed @SYS/can_log.txt.
Statustexts are mirrored to the onboard log by GCS itself, so no
explicit AP_Logger::Write_Message call is needed here.
Once the CAN log buffer gets near to full, the check for remaining space
can pass even though there is insufficient space left in the buffer
for the actual log message after formatting.
The space for the tag is correctly measured, so the `snprintf` will
never perform a short write. However, the `vsnprintf` will. Though it
does not write too much, it pushes `_log_pos` past the end of the buffer
as it returns the amount that would be written, rather than the amount
that actually was written.
In this case, the test on the next call of the function aims to reset
`_log_pos` to the start. Unfortunately, as that variable is unsigned,
the subtraction from `LOG_BUFFER_SIZE` will result in a large positive
number, falsely stating that there is enough space. This will also then
give the `snprintf` and `vsnprintf` a large positive space for them to
write into, so they will write past the end of the buffer and corrupt
the heap and crash the system.
Fix by making the variable and comparison properly signed. This will
give a problem if log messages get into the billions of characters, but
this is unlikely to occur.
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
this supports logging of all bxCAN and CANFD frames, which helps with
debugging tricky CAN support issues and for the development of new CAN
driver lua scripts
keep a record of which bus we have registered a callback for and only
unregister with that bus. This prevents us unregistering a multicast
callback when disconnecting from MAVCAN
Thomas Watson
bugobliterator
Peter Barker
Andrew Tridgell
Mykhailo Kuznietsov
Tom Pittenger
Randy Mackay