Skip to main content
M.Holch
Associate II
November 4, 2021
Question

empty Map>. begin() returns NULL

  • November 4, 2021
  • 2 replies
  • 1963 views

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

cpp.sh/8mruw

// 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

This topic has been closed for replies.

2 replies

Pavel A.
Super User
November 4, 2021

Where is your heap? Do you know that 0 is a valid RAM address on some STM32s ?

TDK
Super User
November 4, 2021

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."
M.Holch
M.HolchAuthor
Associate II
November 6, 2021

compare Test returns TRUE for 32bit IT compare.. and FALSE for the 64bit IT compare...

TDK
Super User
November 6, 2021

Seems like a bug to me. Pass it on to the GCC folks.

https://gcc.gnu.org/bugs/

You could also check to see if there's an updated toolchain available.

"If you feel a post has answered your question, please click ""Accept as Solution""."