mirror of
https://github.com/esphome/esphome.git
synced 2024-12-02 03:34:18 +01:00
7963abb27a
There is a race condition where a BedJet unit previously had its BLE "notify" flag enabled, and it continues to broadcast these notify packets even after the ESP32 (and BLEClient) goes away, such as during a crash or unplugging power. BLEClient::setup_priority=AFTER_BLUETOOTH, while BedJetHub::setup_priority=AFTER_WIFI. When the ESP32 starts back up again, BLEClient::setup() happens first and will start receiving the BLE notify packets almost immediately. Since we register the BLEClient child from codegen, BedJetHub is registered as a child already by this point, so BLEClient dispatches the notify status packet (and other gatt events) to the BedJetHub handler, even though BedJetHub::setup() has not been called yet. We initialize BedJetHub::codec_ in setup(), so if BLEClient starts dispatching gatt events before setup() is called, then codec_ will not be initialized yet. This causes BedJetHub's gatt notify handler to call `this->codec_->decode_notify()` on an uninitialized null pointer. Since invoking a method does not have to dereference the pointer, that method invocation is allowed; but later trying to access memory on that instance results in a StoreProhibited panic. Changing the BedJetHub's setup_priority to BLUETOOTH causes it to be setup before BLEClient, so that by the time BLEClient starts to receive BLE packets, BedJetHub is ready to receive them. |
||
---|---|---|
.. | ||
climate | ||
fan | ||
__init__.py | ||
bedjet_child.h | ||
bedjet_codec.cpp | ||
bedjet_codec.h | ||
bedjet_const.h | ||
bedjet_hub.cpp | ||
bedjet_hub.h |