0

I have a problem executing my application code when debugged in MODE=release. Whereas it executes without a problem in debugging mode.

I tried debugging the code and tried almost everything bound to my capacities, and I ran out of options.

Below I provide the output from gdb, valgring and the original application code. I hope someone can guide me to the solution.

gdb:

Program received signal SIGSEGV, Segmentation fault.
Mac1609_4::EDCA::queuePacket (this=0x0, ac=Mac1609_4::AC_VO, msg=0x11f8da0)
    at veins/modules/mac/ieee80211p/Mac1609_4.cc:582
582     if (maxQueueSize && myQueues[ac].queue.size() >= maxQueueSize) { // FIXME: crash here
(gdb) bt
#0  Mac1609_4::EDCA::queuePacket (this=0x0, ac=Mac1609_4::AC_VO, msg=0x11f8da0)
    at veins/modules/mac/ieee80211p/Mac1609_4.cc:582
#1  0x00007fffeff6d54d in Mac1609_4::handleUpperMsg (this=0x117bb20, msg=
    0x11f8da0) at veins/modules/mac/ieee80211p/Mac1609_4.cc:306
#2  0x00007fffefe756c9 in BaseLayer::handleMessage (this=0x117bb20, 
    msg=0x11f8da0) at veins/base/modules/BaseLayer.cc:81
#3  0x00007ffff6f2843e in cSimulation::doOneEvent (this=0x764ad0, mod=
    0x117bb20) at csimulation.cc:617
#4  0x00007ffff72a10c1 in Cmdenv::simulate (this=0x7648e0) at cmdenv.cc:425
#5  0x00007ffff72a090e in Cmdenv::run (this=0x7648e0) at cmdenv.cc:292
#6  0x00007ffff77d3e03 in EnvirBase::run (this=0x7648e0, argc=11, 
    argv=0x7fffffffe008, configobject=0x740630) at envirbase.cc:279
#7  0x00007ffff77d13fc in setupUserInterface (argc=11, argv=0x7fffffffe008)
    at startup.cc:239
#8  0x00007ffff77d1c52 in evMain (argc=11, argv=0x7fffffffe008) at evmain.cc:38
#9  0x00000000004017db in main (argc=11, argv=0x7fffffffe008) at opp_run.cc:298

prints in gdb: note the address of maxQueueSize (0x3c) corresponding to the output from valgrind

(gdb) p this
$1 = (Mac1609_4::EDCA *) 0x0
(gdb) p maxQueueSize 
Cannot access memory at address 0x3c
(gdb) p myQueues 
Cannot access memory at address 0x8
(gdb) p myQueues[ac].queue.size() 
Attempt to take address of value not located in memory.

Valgrind: For the same function, i.e., queuePacket() Valgrind says:

    ==10224== Conditional jump or move depends on uninitialised value(s)
==10224==    at 0xD043749: std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<t_channel const, Mac1609_4::EDCA*> >*, std::_Rb_tree_node<std::pair<t_channel const, Mac1609_4::EDCA*> >*, t_channel const&) (stl_tree.h:1141)
==10224==    by 0xD0436F0: std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::lower_bound(t_channel const&) (stl_tree.h:879)
==10224==    by 0xD0426CC: std::map<t_channel, Mac1609_4::EDCA*, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::lower_bound(t_channel const&) (stl_map.h:864)
==10224==    by 0xD03E6CE: std::map<t_channel, Mac1609_4::EDCA*, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::operator[](t_channel const&) (stl_map.h:461)
==10224==    by 0xD03B54D: Mac1609_4::handleUpperMsg(cMessage*) (Mac1609_4.cc:306)
==10224==    by 0xCF43DB8: BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:81)
==10224==    by 0x5B7543D: cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:617)
==10224==    by 0x57740C0: Cmdenv::simulate() (cmdenv.cc:425)
==10224==    by 0x577390D: Cmdenv::run() (cmdenv.cc:292)
==10224==    by 0x5225E02: EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:279)
==10224==    by 0x52233FB: setupUserInterface(int, char**) (startup.cc:239)
==10224==    by 0x5223C51: evMain (evmain.cc:38)
==10224== 
==10224== Conditional jump or move depends on uninitialised value(s)
==10224==    at 0xD042B45: std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<t_channel const, Mac1609_4::EDCA*> >, t_channel const&) (stl_tree.h:1422)
==10224==    by 0xD04280C: std::_Rb_tree_iterator<std::pair<t_channel const, Mac1609_4::EDCA*> > std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<t_channel const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::piecewise_construct_t const&, std::tuple<t_channel const&>&&, std::tuple<>&&) (stl_tree.h:1673)
==10224==    by 0xD03E761: std::map<t_channel, Mac1609_4::EDCA*, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::operator[](t_channel const&) (stl_map.h:465)
==10224==    by 0xD03B54D: Mac1609_4::handleUpperMsg(cMessage*) (Mac1609_4.cc:306)
==10224==    by 0xCF43DB8: BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:81)
==10224==    by 0x5B7543D: cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:617)
==10224==    by 0x57740C0: Cmdenv::simulate() (cmdenv.cc:425)
==10224==    by 0x577390D: Cmdenv::run() (cmdenv.cc:292)
==10224==    by 0x5225E02: EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:279)
==10224==    by 0x52233FB: setupUserInterface(int, char**) (startup.cc:239)
==10224==    by 0x5223C51: evMain (evmain.cc:38)
==10224==    by 0x4017DA: main (opp_run.cc:298)
==10224== 
==10224== Conditional jump or move depends on uninitialised value(s)
==10224==    at 0x6A8FC0F: std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==10224==    by 0xD042EE1: std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::_M_insert_node(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node<std::pair<t_channel const, Mac1609_4::EDCA*> >*) (stl_tree.h:1575)
==10224==    by 0xD042858: std::_Rb_tree_iterator<std::pair<t_channel const, Mac1609_4::EDCA*> > std::_Rb_tree<t_channel, std::pair<t_channel const, Mac1609_4::EDCA*>, std::_Select1st<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<t_channel const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<t_channel const, Mac1609_4::EDCA*> >, std::piecewise_construct_t const&, std::tuple<t_channel const&>&&, std::tuple<>&&) (stl_tree.h:1676)
==10224==    by 0xD03E761: std::map<t_channel, Mac1609_4::EDCA*, std::less<t_channel>, std::allocator<std::pair<t_channel const, Mac1609_4::EDCA*> > >::operator[](t_channel const&) (stl_map.h:465)
==10224==    by 0xD03B54D: Mac1609_4::handleUpperMsg(cMessage*) (Mac1609_4.cc:306)
==10224==    by 0xCF43DB8: BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:81)
==10224==    by 0x5B7543D: cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:617)
==10224==    by 0x57740C0: Cmdenv::simulate() (cmdenv.cc:425)
==10224==    by 0x577390D: Cmdenv::run() (cmdenv.cc:292)
==10224==    by 0x5225E02: EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:279)
==10224==    by 0x52233FB: setupUserInterface(int, char**) (startup.cc:239)
==10224==    by 0x5223C51: evMain (evmain.cc:38)
==10224== 
==10224== Invalid read of size 4
==10224==    at 0xD03B987: Mac1609_4::EDCA::queuePacket(Mac1609_4::t_access_category, WaveShortMessage*) (Mac1609_4.cc:582)
==10224==    by 0xD03B55C: Mac1609_4::handleUpperMsg(cMessage*) (Mac1609_4.cc:306)
==10224==    by 0xCF43DB8: BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:81)
==10224==    by 0x5B7543D: cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:617)
==10224==    by 0x57740C0: Cmdenv::simulate() (cmdenv.cc:425)
==10224==    by 0x577390D: Cmdenv::run() (cmdenv.cc:292)
==10224==    by 0x5225E02: EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:279)
==10224==    by 0x52233FB: setupUserInterface(int, char**) (startup.cc:239)
==10224==    by 0x5223C51: evMain (evmain.cc:38)
==10224==    by 0x4017DA: main (opp_run.cc:298)
==10224==  Address 0x3c is not stack'd, malloc'd or (recently) free'd
==10224== 
==10224== 
==10224== Process terminating with default action of signal 11 (SIGSEGV)
==10224==  Access not within mapped region at address 0x3C
==10224==    at 0xD03B987: Mac1609_4::EDCA::queuePacket(Mac1609_4::t_access_category, WaveShortMessage*) (Mac1609_4.cc:582)
==10224==    by 0xD03B55C: Mac1609_4::handleUpperMsg(cMessage*) (Mac1609_4.cc:306)
==10224==    by 0xCF43DB8: BaseLayer::handleMessage(cMessage*) (BaseLayer.cc:81)
==10224==    by 0x5B7543D: cSimulation::doOneEvent(cSimpleModule*) (csimulation.cc:617)
==10224==    by 0x57740C0: Cmdenv::simulate() (cmdenv.cc:425)
==10224==    by 0x577390D: Cmdenv::run() (cmdenv.cc:292)
==10224==    by 0x5225E02: EnvirBase::run(int, char**, cConfiguration*) (envirbase.cc:279)
==10224==    by 0x52233FB: setupUserInterface(int, char**) (startup.cc:239)
==10224==    by 0x5223C51: evMain (evmain.cc:38)
==10224==    by 0x4017DA: main (opp_run.cc:298)
==10224==  If you believe this happened as a result of a stack
==10224==  overflow in your program's main thread (unlikely but
==10224==  possible), you can try to increase the size of the
==10224==  main thread stack using the --main-stacksize= flag.
==10224==  The main thread stack size used in this run was 8388608.
==10224== 
==10224== HEAP SUMMARY:
==10224==     in use at exit: 10,620,167 bytes in 137,073 blocks
==10224==   total heap usage: 891,187 allocs, 754,114 frees, 88,925,514 bytes allocated

Original function in C++:

int Mac1609_4::EDCA::queuePacket(t_access_category ac,WaveShortMessage* msg) {
    if (maxQueueSize && myQueues[ac].queue.size() >= maxQueueSize) { // FIXME: crash here
        delete msg;
        return -1;
    }
    myQueues[ac].queue.push(msg);
    return myQueues[ac].queue.size();
}

UPDATE 1: There was a complaint for the code below and it was solved, as suggested by @PaulMcKenzie and @WhozCraig, by following proper map::erase() usage: How can I delete elements of a std::map with an iterator?

Original function in C++: getNonCrossingRoads()

std::map<TraCIRoad*, std::list<std::pair<Coord, Coord> > > structure = getTrafficLightStructure();

std::set<std::string> allLanes = cccTable.getLanes();
for (auto it : structure){      // FIXME: problem occurs here
    TraCIRoad* road = it.first;
    auto found = allLanes.find(road->getEndLane());
    if(found == allLanes.end()) { 
        structure.erase(road);
    }
}
Community
  • 1
  • 1
cross
  • 1,018
  • 13
  • 32
  • `structure.erase(road);` What if `road` happens to be the current iterator in the loop? Also, why are you using pointers as keys into a map? That in itself is wrought with peril. Maybe see [this](http://stackoverflow.com/questions/4600567/how-can-i-delete-elements-of-a-stdmap-with-an-iterator)? – PaulMcKenzie Aug 19 '16 at 21:22
  • @PaulMcKenzie sorry, can you be a bit more verbose... after 13 hours in front of the PC I cannot follow anymore. The map was written by someone else, and I have to follow that interface – cross Aug 19 '16 at 21:59
  • 1
    Read the link. It should be clear. When you call `erase`, the entry goes away, and any iterators pointing to that entry become invalidated. So what if the iterator in the loop happens to be pointing to the one you're erasing? When the loop needs to increment that iterator to the next entry, that iterator is no longer valid. Again, read the link as to how to properly erase items from a map while you're iterating over the map. – PaulMcKenzie Aug 19 '16 at 22:25
  • Concur with Paul. Not only is that a problem, it's *guaranteed* to be a problem when that if-condition holds true. When that erase happens you *will* invalidate your ranged-for enumeration. Ranged-for should not be used to modify the underlying sequence being enumerated (and that is exactly what you're doing when that if-condition holds). Use a regular iterator and proper advancement techniques, all documented excessively in the link he provided. – WhozCraig Aug 19 '16 at 22:43
  • @PaulMcKenzie @WhozCraig you were correct, those issues were solved by using properly `erase` as given in the link (@comment number 1) – cross Aug 20 '16 at 11:13

0 Answers0