‎2021-11-03 07:26 PM
Hello
I'm lost.. my code gets HARD-HANDLE due to illegal access, have traced it down to my MAP.
but have NO clue to why :(
My code have a map of shared pointers. with a key uint64_t.
A loop of the elements before any is added makes it crash.
now i can see the .begin() on my empty maps return NULL, WTF. I would not expect this to ever happen ?
The MAP looks to be created correct, and both left & right is set to "END"
but when using the begin(), it still return NULL
Now comes the wierd part... if i use uint32_t as key... it works :tired_face: and begin & end both return "end"
This is a reduced version in normal "c++"
my result on my STM32 is:
it32_1 : 0x24004700
it32_2 : 0x24004700
it64_1 : 0x0
it64_2 : 0x240046e5
// map::begin/end
#include <iostream>
#include <map>
#include <memory>
class test
{
public:
test(){};
~test(){};
};
int main ()
{
std::map<uint32_t, std::shared_ptr<test>> testMap32;
std::map<uint64_t, std::shared_ptr<test>> testMap64;
auto it32_1 = testMap32.begin();
auto it32_2 = testMap32.end();
auto it64_1 = testMap64.begin();
auto it64_2 = testMap64.end();
printf("it32_1 : %p\r\n",it32_1);
printf("it32_2 : %p\r\n",it32_2);
printf("it64_1 : %p\r\n",it64_1);
printf("it64_2 : %p\r\n",it64_2);
return 0;
}
Is this a BUG in the compiler ???
I have updated to IDE 1.7
Update:
using key:
uint8_t Fails
uint16_t Success
‎2021-11-04 08:50 AM
Where is your heap? Do you know that 0 is a valid RAM address on some STM32s ?
‎2021-11-04 10:13 AM
It's unclear what printf %p does with an iterator passed as an argument. An iterator is not a pointer, and you can't dereference the end iterator. If that's not it, the only explanation I can think of is a failed and unhandled memory allocation which makes its way back as a nullptr.
Does the comparison it32_1 == it32_2 succeed? And how about it64_1 == it64_2?
In this instance, even if 0 is a valid memory address, it's still wrong as end() and begin() should be identical for an empty container. But again, it's unclear what is actually being printed here.
Edit: this was meant to be a top-level post, not a reply.
‎2021-11-06 09:59 AM
compare Test returns TRUE for 32bit IT compare.. and FALSE for the 64bit IT compare...
‎2021-11-06 11:15 AM
Seems like a bug to me. Pass it on to the GCC folks.
You could also check to see if there's an updated toolchain available.