-
Notifications
You must be signed in to change notification settings - Fork 74
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
OTA_SignalEvent has undefined behaviour #218
Comments
The same thing in
and in OTA_ActivateNewImage (this time with the insufficient check):
|
Thank you for bringing these issues to our attention. We will work on adding further checks for these functions. |
+1 Want to add that I believe this doesn't even need such a hard/tight preemptive race like theorized above, but could even happen with e.g. cooperative FreeRTOS timer race, because a timer may just expire when That was my theory for some time, until I realized OTA_Shutdown does not clear started timers at all. |
Hi, apologies for the delay. OTA_Shutdown has now been updated to clear started timers here: #413. |
Thanks. (One could sure say you shouldn't do pass packets to OTA after you have called the shutdown method, but better would be to also guard this path. It at least needs to be documented, and there I also have to agree with fhars' #224 - it is not only not well abstracted but also not at all documented. "So one has to rifle through the source of the library" also matches my memory of getting that part right. |
PR #440 provides the solution for this. Once the OTA_Init called, the function pointer is set and never reset even it's shutdowned. I'm going to close this issue. Any feedback is welcome. Thanks. |
This line:
ota-for-aws-iot-embedded-sdk/source/ota.c
Line 2933 in 0d6f669
may dereference a null pointer, especially after an
OTA_Shutdown(ticks, false)
. (Note that checking that pOtaInterface is valid before the call is not sufficient here, as theshutdownHandler
might memsetotaAgent
to zero between the check and the call). Another possible race condition is in the calledsend
method, as (in the FreeRTOS case) the queue itself might be deinitialized by the time execution reaches theconfigAssert( pxQueue );
inxQueueGenericSend
, although this error path is currently masked by #217.The text was updated successfully, but these errors were encountered: