1

I have a std::map to store pointers to objects associated with their respective ID. When I loop on the map to get the content of it, I get a wrong return on first try, but a correct one on next tries:

class session_list { private: ... static std::map<uint, session*> session_list; ... public: ... static void add_exclusive_session(uint id, session& session); ... std::map<uint, session*>& get_session_list() ; }; 
std::map<uint, core_base_session*>& core_session_list::get_session_list() { return session_list; } void session_list::add_exclusive_session(uint id, session& session) { guard g(mutex); if (session.disconnect_reason != core_sd_connected) return; session * previous_session = get_session(id, g); session_list.emplace(id, &session); if ((previous_session != nullptr) &&(previous_session != &session)) { previous_session->disconnect(core_sd_peer_duplicated); } } 
std::map<uint, session*> session_list = session.parent.session_list->get_session_list(); for ( auto& it: session_list) { printf("\n\tSESSION N° %d \t %p" , it.first, it.second); } 

It dumps this :

2016-08-18 14:57:23.103881 [info] DBG_ SESSION N° 1402969504 0x7efc400008c0 <=== APPEARS TWICE SESSION N° 574745422 0x1a469f0 SESSION N° 1402969504 0x7efc400008c0 <=== APPEARS TWICE SESSION N° 1502939797 0x7efc48000ca0 SESSION N° 1510611043 0x7efc3c000ca0 2016-08-18 14:57:38.245280 [info] DBG_ SESSION N° 2011917896 0x7efc44000ca0 <=== APPEARS NOT ON FIRST TRY SESSION N° 574745422 0x1a469f0 SESSION N° 1402969504 0x7efc400008c0 SESSION N° 1502939797 0x7efc48000ca0 SESSION N° 1510611043 0x7efc3c000ca0 

Any idea?

8
  • 1
    Would you post get_session_list code ? Commented Aug 18, 2016 at 14:18
  • My first guess would be that the first DBG_ output is actually output from two executions of the snippet in question, displayed back-to-back. Commented Aug 18, 2016 at 14:23
  • 1
    Are you sure the list of sessions didn't change during the fifteen seconds between the log records? You're likely to have to produce an MCVE (minimal reproducible example), and you're likely to find it hard to produce an MCVE that reproduces the problem, IMO. But without us knowing a lot more about what's going on, we won't be able to help much, I think. Commented Aug 18, 2016 at 14:23
  • @NPE DBG_ output is the execution from the same snippet shown above, twice. Commented Aug 18, 2016 at 14:24
  • 2
    You didn't show how the map is created, so there is no point in us speculating on the infinite possible things that might be wrong. UB is hard enough to diagnose, without you not providing anything to use. "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example" Commented Aug 18, 2016 at 14:33

1 Answer 1

1

So what we appear to see here is that a std::map object contains two identical keys. Let's enumerate the possibilities that would explain this behaviour (from least likely to most likely):

  • your compiler's std::map is fundamentally broken and allows multiple identical keys;
  • you have an undefined behaviour somewhere in your code that corrupts session_list;
  • the first sequence of SESSION N° lines is produced by the code in question getting executed more than once, e.g.

    # run 1 SESSION N° 1402969504 0x7efc400008c0 <=== APPEARS TWICE # run 2 SESSION N° 574745422 0x1a469f0 SESSION N° 1402969504 0x7efc400008c0 <=== APPEARS TWICE SESSION N° 1502939797 0x7efc48000ca0 SESSION N° 1510611043 0x7efc3c000ca0 

My money's on the last one. It's hard to tell how likely it is without seeing more of your code.

Sign up to request clarification or add additional context in comments.

6 Comments

My compiler is standard GNU g++ g++ (Debian 4.9.2-10) 4.9.2
I don't get your 3rd point. There is two runs of the DBG_ command. This command run the snippet once.
That version of g++ and its library libstdc++, due to being included in Debian Stable, clearly cannot have a map so "fundamentally broken" as this... so it's not the implementation's fault.
@MicroCheapFx: There is nothing about DBG_ in the code you've posted, so we can only guess when and how it gets printed.
Since the keys must be increasing in the map, it's a different spot that is likely the break between two executions of the loop.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.