bug with maps/unordered maps (C++)

[mzimmers]

Hi all -

I've uncovered what looks like a bug in the implementation of maps and unordered maps. To whom would I report this?

Thanks...

[kolban]

Do you mean the C++ class known as std::map?

What I'd probably suggest you do is create a detailed PDF describing the nature of the problem, steps to recreate, what environment it is occurring within and any other relevant details you think would be useful for a someone to read and understand as much of the puzzle as possible. Post a link to the PDF. That way you should only have to write the text once and if it needs to be shipped around it will already have been written. If there is a puzzle in this area, one might want to try writing a sample that will compile on the ESP32 and also compile on Linux and see if there is a difference in operation.

[mzimmers]

Hey Neil - I can try to put something together, but might be tough to create a repeatable example. At this point, I'm mostly interested in what governing body is the custodian of the code. If they have a forum, even a github one, I might be able to locate someone who could act on the incomplete information that I have.

Is Espressif the "owner" of the tool chain?

[kolban]

I'm going to guess that the toolchain comes from the "crosstool-NG" project with additions for Xtensa ... see:

https://github.com/espressif/crosstool-NG

and

http://crosstool-ng.github.io/

[ESP_Sprite]

FWIW, if you can create an example or describe the situation this occurs in, you can file it as an issue in the esp-idf github anyway. If anything, we can decide if this is ESP32-specific or possibly a general libstdc++ error and pass it on upstream.

[mzimmers]

After a lot of trial and error, I no longer believe that this is a bug in the STL. Somehow, my unordered_map was getting corrupted. I traced it to a call to xQueueReceive() that seems to have been overwriting my stack area.

The fix was to dynamically create and destroy instances of the object containing the unordered_map every time I needed one, rather than using an automatic variable. Probably good form anyway, given that the routine was of indefinite duration.

Thanks to those who looked...