Closed briandilley closed 2 months ago
Does it fail on the first push to the vector? If not, are you sure that you are not exceeding the vector's capacity?
I wonder if you are falling foul of what is called the "Static Initialisation Fiasco" if the DINSystem
instance is declared in a different translation unit to the gpioInterruptCallbacks
vector.
Is it possible that the call to push_back
is occurring before the vector is initialised?
It occurs on the first push to that vector. Pushes to other static vectors on the same class happen before this one and are successful. Also, I call the HALAL::setEnabled(false)
as the first thing in the program basically... so I would hope that after that call everything on that class is initialized. It's essentially this:
HALAL::setEnabled(false);
... STM32 Peripheral initialization ...
... call to a function to perform "System" initialization (where this problem is occurring) ...
HALAL::setEnabled(true);
... start FreeRTOS ...
Ok - new information: At the top of the registration methods I query the size and capacity of the vectors and they're WAY off... even the ones that were "working" before. So I guess their memory has been corrupted some how? I'm fairly new to the embedded stuff.
void HALAL::registerGpioInterruptCallback(HALALGpioInterruptCallback callback) {
auto size = HALAL::gpioInterruptCallbacks.size();
auto capacity = HALAL::gpioInterruptCallbacks.capacity();
HALAL::gpioInterruptCallbacks.push_back(callback);
}
void HALAL::registerTimerPeriodElapsedCallback(HALALTimerPeriodElapsedCallback callback) {
auto size = HALAL::timerPeriodElapsedCallbacks.size(); // reports numbers like 4294967277
auto capacity = HALAL::timerPeriodElapsedCallbacks.capacity();
timerPeriodElapsedCallbacks.push_back(callback);
}
Did you manage to resolve this?
I have the following class:
with the following implementation:
I use it in the constructor of some "System" objects to register callbacks for interrupts like so:
For whatever reason that
registerGpioInterruptCallback
call fails inmemory.h
line 1806 where the vector is using it to create a copy of the delegate for storage within the vector (I think):Here's the stack:
The weirdest thing is that the other registration method(s) work just fine in other objects using the same pattern (registration in the constructor). (There are actually a lot more registration methods, i just left them out for brevity). The value of
p
looks fine to me, it's the same value as thep_end
member of the vector.... so I assume it's fine.