-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid nullptr dereference on bad rcmap value entry #28033
Avoid nullptr dereference on bad rcmap value entry #28033
Conversation
9112bc4
to
3005d14
Compare
I've added an additional patch to MSP to avoid a similar problem. There are almost certainly more in the codebase, but I want to know this is an acceptable solution before patching them all. |
b0c3d87
to
d00f1b5
Compare
Problems around optimisation again on Pixhawk1-1M-bdshot; elf-diff shows many small increases in random methods
|
@@ -8,16 +8,17 @@ | |||
*/ | |||
void Plane::set_control_channels(void) | |||
{ | |||
// the library gaurantees that these are non-nullptr: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// the library gaurantees that these are non-nullptr: | |
// the library guarantees that these are non-nullptr: |
d00f1b5
to
1089f6c
Compare
Setting a bad rcmap entry doesn't just hard-fault the autopilot but ensures you have to reset all of your parameters before you have a working autopilot again.
This has been the case for a very long time. But perhaps we should fix it?
Checking the library return values for nullptr doesn't help if we have already persisted the parameters - next time you boot you'll not populate e.g.
channel_roll
with a valid pointer and will then segfault. So we use a "dummy channel" instead.A new record for shortest autotest.