My binary is crashing. On running the core dump, I found the following :
#0 0x00a6a363 in memmove () from /lib/tls/libc.so.6
(gdb) frame 1
#1 0x083a108c in std::__copy_trivial<piola::piolaOrderBook*> (__first=0xb277f2c4, __last=0xb277f2bc, __result=0xb277f2c0)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_algobase.h:258
258 std::memmove(__result, __first, sizeof(_Tp) * (__last - __first));
(gdb) frame 2
#2 0x083a0ad6 in std::__copy_aux2<piola::piolaOrderBook*> (__first=0xb277f2c4, __last=0xb277f2bc, __result=0xb277f2c0)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_algobase.h:279
279 { return std::__copy_trivial(__first, __last, __result); }
(gdb) frame 3
#3 0x083a02d1 in std::__copy_ni2<piola::piolaOrderBook**, __gnu_cxx::__normal_iterator<piola::piolaOrderBook**, std::vector<piola::piolaOrderBook*, std::allocator<emapi::EmapiOrderBook*> > > > (__first=0xb277f2c4, __last=0xb277f2bc, __result=
{_M_current = 0xb277f2c0})
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_algobase.h:296
296 return _OutputIterator(std::__copy_aux2(__first, __last, __result.base(),
(gdb) frame 4
#4 0x0839f1b0 in std::__copy_ni1<__gnu_cxx::__normal_iterator<piola::piolaOrderBook**, std::vector<piola::piolaOrderBook*, std::allocator<piola::piolaOrderBook*> > >, __gnu_cxx::__normal_iterator<piola::piolaOrderBook**, std::vector<piola::piolaOrderBook*, std::allocator<piola::piolaOrderBook*> > > > (__first={_M_current = 0xb277f2c4}, __last=
{_M_current = 0xb277f2bc}, __result={_M_current = 0xb277f2c0})
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_algobase.h:317
317 return std::__copy_ni2(__first.base(), __last.base(),
(gdb) frame 5
#5 0x0839d676 in std::copy<__gnu_cxx::__normal_iterator<piola::piolaOrderBook**, std::vector<piola::piolaOrderBook*, std::allocator<piola::piolaOrderBook*> > >, __gnu_cxx::__normal_iterator<piola::piolaOrderBook**, std::vector<piola::piolaOrderBook*, std::allocator<piola::piolaOrderBook*> > > > (__first={_M_current = 0xb277f2c4}, __last={_M_current = 0xb277f2bc},
__result={_M_current = 0xb277f2c0})
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_algobase.h:358
358 return std::__copy_ni1(__first, __last, __result, __Normal());
(gdb)
Most of this is cryptic to me, however on looking up memmove it seems like the code crashed because it could not handle the deletions from the vector (since deleting from a vector is a very heavy operation for large vectors) ?
Am I correct ? If yes, how can I fix this issue (apart from fixing the design of course) ?
The code is here :
for (orderbkIterator = vOrderBook.begin(); orderbkIterator != vOrderBook.end(); orderbkIterator++)
{
if ( (*(*orderbkIterator)->getOrderBookId()) == *(TradableInst->getOrderBookId()) )
{
long long a = (*(*orderbkIterator)->getOrderBookId());
ADDVLOG(LOG_INFO, "Removing record (%lld) from vOrderBook", a );
vOrderBook.erase(orderbkIterator);
}
From std::vector::erase():
Iterators and references to the erased elements and to the elements between them and the end of the container are invalidated. Past-the-end iterator is also invalidated.
so orderbkIterator will be invalid when next incremented if the erase() was called. Change the structure of the loop as erase() returns the next iterator after the iterator that was removed, meaning only increment if an erase() did not happen:
for (orderbkIterator = vOrderBook.begin(); orderbkIterator != vOrderBook.end();)
{
if (...)
{
orderbkIterator = vOrderBook.erase(orderbkIterator);
}
else
{
++orderbkIterator;
}
}
I'm pretty sure that
vOrderBook.erase(orderbkIterator);
will invalidate the iterator. Continuing the increment it will lead to undefined results.
The remove erase idiom will prevent many of the pitfalls with invalidated iterators.
Rewritting the loop using this idiom would look something like the following:
vOrderBook.erase(
std::remove_if(vOrderBook.begin(), vOrderBook.end(), <unary-predicate>),
vOrderBook.end());
The unary-predicate could be a lambda or a functor.
Related
My program seems to be crashing while inserting and int into a set, and I cannot track down the reason for this. Here is there relevant code:
bool request::check_list(std::vector<int> search_vec)
{
std::set<int> *tmp_ptr = create_int_set();
boost::shared_ptr<std::set<int> > c_list(tmp_ptr);
if(aerospike_query_foreach(as, &err, NULL, &query, process_set, &c_list) != AEROSPIKE_OK)
{
return false;
}
for(int i = 0; i < search_vec.size(); i++)
{
if(c_list->find(search_vec[i]) != c_list->end())
{
c_list_value_ = search_vec[i];
return true;
}
}
return false;
}
bool request::process_set(const as_val *val, void * udata)
{
try
{
boost::shared_ptr<std::set<int> > c_set = *(boost::shared_ptr<std::set<int> > *)(udata);
if(val == NULL)
{
return true;
}
if(val->type == AS_REC)
{
if (val!=NULL)
{
as_record *rec = as_record_fromval(val);
if (rec!=NULL)
{
as_integer* c_id = as_record_get_integer(rec,"c_id");
int cid = 0;
cid = boost::lexical_cast<int>(c_id->value);
if(c_set != nullptr)
{
c_set->insert(c_id);
}
as_record_destroy(rec);
as_integer_destroy(c_id);
}
}
return true;
}catch(...){}
return false;
}
The line c_set->insert(c_id); is causing a segfault. Here is this backtrace of the crash:
#0 0x00007f2064299f94 in std::_Rb_tree_rotate_right(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&) () from /usr/lib64/libstdc++.so.6
#1 0x00007f206429a12b in std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib64/libstdc++.so.6
#2 0x00000000004829d9 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_<int const&> (this=0x7f1fcc005440, __x=0x0, __p=0x7f1f3c0009a0, __v=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tree.h:981
#3 0x000000000047f1e0 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_unique<int const&> (this=0x7f1fcc005440, __v=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tree.h:1299
#4 0x000000000047c473 in std::set<int, std::less<int>, std::allocator<int> >::insert (this=0x7f1fcc005440, __x=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_set.h:415
#5 0x00000000004765ee in request::process_set (val=0x7f20159e73e0, udata=0x7f200b9d6620) at ../../request.cpp:1862
I am assuming there is a problem where the set is not being initialized, or something similar to that. Here is how I create and pass the set from the another function, I have tried two ways to create it:
boost::shared_ptr<std::set<int> > c_list(new std::set<int>());
and
std::set<int> *tmp_ptr = create_int_set();
boost::shared_ptr<std::set<int> > c_list(tmp_ptr);
std::set<int>* request::create_int_set()
{
return new std::set<int>();
}
The calling function is a callback function from a database driver, that takes in a few different objects, most notably however are the process_set and the c_list, which is passed as a void*:
aerospike_query_foreach(as, &err, NULL, &query, process_set, &c_list)
This crash does not happen all the time, in fact it is fairly rare, which makes me think there is something I am doing wrong, some sort of undefined behavior. Any help would be greatly appreciated!
The aerospike APi documentation says for the callback (i.e. process_set(), here):
Execute a query and call the callback function for each result item.
Multiple threads will likely be calling the callback in parallel.
Therefore, your callback implementation should be thread safe.
As several threads might insert at the same time in the same set (the one pointed to by your shared pointer), you'll get race conditions and hence undefined behaviour !
So I think that you should protect at least your set insertion block with a lock_guard on a mutex.
Important edit: boost::shared_ptr<> can't assumed to be thread safe. In the examples on boost.org, they suggest that a shared pointer going out of scope might cause a race. It may therefore be highly advisable to follow Matthew Moss's suggestion in the comments and use a raw pointer to the set within the bounds of process_set().
part 2 to my : https://stackoverflow.com/questions/21780627/c-map-of-maps-typedef-doubts-queries
I then move ahead to create vectors (resizeable) of InnerMap, MiddlMap and do the following:
InnerMap inmap;
vector<InnerMap> vec_inmap;
vec_inmap.resize (8);
int vec_inmap_sz = 8;
vec_inmap.insert (vec_inmap.end (), 8, inmap);
vector<InnerMap>::iterator vec_inmap_it = vec_inmap.begin ();
InnerMap::iterator inmap_it;
MiddlMap mdmap, curr_mdmap;
vector<MiddlMap> vec_mdmap;
vec_mdmap.resize (8);
int vec_mdmap_sz = 8;
vec_mdmap.insert (vec_mdmap.end (), 8, mdmap);
vector<MiddlMap>::iterator vec_mdmap_it = vec_mdmap.begin ();
MiddlMap::iterator mdmap_it;
OuterMap otmap;
OuterMap::iterator otmap_it;
i.e. I store (empty) copies of inmap and mdmap (Q. is it that these copies are by reference ?) in the respective vectors, and then pick up these later from the vectors through the respective vector iterators, and then fill the maps accordingly. Here is how:
for (i = 0; i != trainSize; i++) {
...
if (curr_key_otmap != int_key) {
otmap[int_key] = *vec_mdmap_it;
vec_mdmap_it++;
mdmap_count++;
if (mdmap_count == vec_mdmap_sz) {
vec_mdmap_sz += 8;
vec_mdmap.resize (vec_mdmap_sz);
vec_mdmap.insert (vec_mdmap.end(), 8, mdmap);
}
curr_key_otmap = int_key;
curr_mdmap = otmap[curr_key_otmap];
}
mdmap_it = curr_mdmap.find (int_val);
if (mdmap_it == curr_mdmap.end ()) {
curr_mdmap[int_val] = *vec_inmap_it; <--
curr_mdmap[int_val][char_str] = 1;
vec_inmap_it++;
inmap_count++;
if (inmap_count == vec_inmap_sz) {
vec_inmap_sz += 8;
vec_inmap.resize (vec_inmap_sz);
vec_inmap.insert (vec_inmap.end(), 8, inmap);
}
} else {
inmap_it = (*mdmap_it).second.find (char_str);
if (inmap_it == (*mdmap_it).second.end ()) {
(*mdmap_it).second[char_str] = 1;
} else {
(*mdmap_it).second[char_str] += 1;
}
}
...
} //for ends
over the course of run time .. i get the following error at the <--ed line: could someone elaborate?
Program received signal SIGSEGV, Segmentation fault.
0x0804f9d4 in __gnu_cxx::new_allocator<std::pair<char* const, int> >::construct (this=0xbffff06f, __p=0x8057428, __val=...)
at /usr/include/c++/4.6/ext/new_allocator.h:108
108 { ::new((void *)__p) _Tp(__val); }
#0 0x0804fa2a in __gnu_cxx::new_allocator<std::pair<char* const, int> >::construct (this=0xbffff1bf, __p=0x8057428, __val=...)
at /usr/include/c++/4.6/ext/new_allocator.h:108
#1 0x0804f3e4 in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, std::less<char*>, std::allocator<std::pair<char* const, int> > >::_M_create_node (this=0x8098d1c, __x=...) at /usr/include/c++/4.6/bits/stl_tree.h:381
#2 0x0804e25f in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, std::less<char*>, std::allocator<std::pair<char* const, int> > >::_M_clone_node (this=0x8098d1c, __x=0xfffffffd) at /usr/include/c++/4.6/bits/stl_tree.h:427
#3 0x0804c645 in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, std::less<char*>, std::allocator<std::pair<char* const, int> > >::_M_copy (this=0x8098d1c, __x=0xfffffffd, __p=0x8098d20) at /usr/include/c++/4.6/bits/stl_tree.h:1036
#4 0x0804bda5 in std::_Rb_tree<char*, std::pair<char* const, int>, std::_Select1st<std::pair<char* const, int> >, std::less<char*>, std::allocator<std::pair<char* const, int> > >::operator= (this=0x8098d1c, __x=...) at /usr/include/c++/4.6/bits/stl_tree.h:945
#5 0x0804a714 in std::map<char*, int, std::less<char*>, std::allocator<std::pair<char* const, int> > >::operator= (this=0x8098d1c, __x=...)
at /usr/include/c++/4.6/bits/stl_map.h:255
#6 0x080493ff in MyProg::classify (trainData=..., testsData=...) at my_prog.cpp:83 <-- this is the line I marked
#7 0x08049c72 in main () at my_prog.cpp:200
Please ask me for edits/clarifications if anything is undecipherable.
You know what, your code is too big that i can't get it all but i think you should have this
vector<InnerMap*>::iterator vec_inmap_it = vec_inmap.begin ();
//instead of
vector<InnerMap>::iterator vec_inmap_it = vec_inmap.begin ();
try it
When you resize a vector, all iterators to that vector become invalid unless that space was already allocated with vector::reserve before the iterators were created. This is because if there is no available memory after currently allocated block, the data will be copied elsewhere. If the relocation happens, on next iteration, vec_inmap_it will then be pointing to unallocated memory that may have been overwritten. Thus undefined behaviour.
// inside for loop
if (mdmap_it == curr_mdmap.end ()) {
curr_mdmap[int_val] = *vec_inmap_it; // here you dereference vec_inmap_it
curr_mdmap[int_val][char_str] = 1;
vec_inmap_it++;
inmap_count++;
if (inmap_count == vec_inmap_sz) {
vec_inmap_sz += 8;
vec_inmap.resize (vec_inmap_sz); // here you resize the vector, vec_inmap_it is now invalid
vec_inmap.insert (vec_inmap.end(), 8, inmap);
}
...
I have the following std::map defined:
//The map holding the list of registered services per partition key.
std::map<SRServicePartitionKey, std::vector<EndPointAddr*>* > mServiceMap;
I have below indicated function whose aim is to remove a specific EndPointAddr* pointer in the vector that is kept in the value of the above defined Map instance. I am getting a SEGABORT in gdb after the following scenario realized:
Add multiple items to the map
Delete the items using the below function one by one.
Add those deleted items again (a few of them)
Delete one item ==> AT THIS POINT I get a sigabort in GDB with the following message:
* glibc detected * /home/holb/DESIGN/ECLB_CP/REPs/V2/eclb_cp/build_output/ServiceRegistrar: double free or corruption (fasttop): 0x00007ffff0002e10 *
GDB Back trace is available at the bottom...
QUESTION
What particular things do you think are wrong in this removal function below? Why do I get this "Double free or corruption" error? What do you think I am missing in the removal function where I first find the item to be deleted, then remove it from the vector and finally deallocate it.
REMOVAL FUNCTION
bool
ServiceRegistrar::removeService(const EndPointAddr & epAddrForRemoval)
{
bool condErased = false;
for(auto it = mServiceMap.begin(); it != mServiceMap.end(); ++it)
{
std::cout << "\tPartition ["
<< (*it).first.getInstanceNo() << ","
<< (*it).first.getContext() << ","
<< (*it).first.getVersion() << "]:"
<< std::endl;
std::vector<EndPointAddr*> * serviceList = (*it).second;
auto found =
std::find_if(serviceList->begin(),
serviceList->end(),
[epAddrForRemoval]( EndPointAddr* otherEPAddr )
{
const EndPointTipcAddr & tipcAddrToRemove = epAddrForRemoval.getImmutableTipcAddress();
const EndPointTipcAddr & otherTipcAddr = otherEPAddr->getImmutableTipcAddress();
return (tipcAddrToRemove.compareTo(otherTipcAddr));
});
EndPointAddr * toBeDeAllocatedEP = *found;
auto toBeErasedEP =
std::remove_if(serviceList->begin(),
serviceList->end(),
[epAddrForRemoval]( EndPointAddr* otherEPAddr )
{
const EndPointTipcAddr & tipcAddrToRemove = epAddrForRemoval.getImmutableTipcAddress();
const EndPointTipcAddr & otherTipcAddr = otherEPAddr->getImmutableTipcAddress();
return (tipcAddrToRemove.compareTo(otherTipcAddr));
});
if(toBeErasedEP != serviceList->end())
{
serviceList->erase(toBeErasedEP, serviceList->end());
condErased = true;
}
if(toBeDeAllocatedEP != 0)
{
!!!!!!!!!!!!LINE 1396 is HERE!!!!!!!!!!!!!!!
delete toBeDeAllocatedEP;
}
} //end of For Loop
return condErased;
}
GDB BackTrace
(gdb) bt
#0 0x00007ffff7026425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7029b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff706439e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff706eb96 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff7681540 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x0000000000434604 in EndPointIpAddr::~EndPointIpAddr (this=0x7ffff0002fb0, __in_chrg=<optimized out>) at /home/holb/DESIGN/ECLB_CP/REPs/V2/eclb_cp/src/control_components/../control_api/api_util/EndPointIpAddr.hpp:28
#6 0x0000000000434660 in EndPointAddr::~EndPointAddr (this=0x7ffff0002f90, __in_chrg=<optimized out>) at /home/holb/DESIGN/ECLB_CP/REPs/V2/eclb_cp/src/control_components/../control_api/api_util/EndPointAddr.hpp:36
#7 0x000000000043c97f in ServiceRegistrar::removeService (this=0x7fffffffdea0, epAddrForRemoval=...) at /home/holb/DESIGN/ECLB_CP/REPs/V2/eclb_cp/src/control_api/ServiceRegistrar.cpp:1396
You appear to be using found without checking if it's valid or not. If you were to fail to find a value and find_if returned serviceList->end(), you'd be dereferencing serviceList->end().
The variable you're storing this dereferenced value to is the one that's causing you trouble later when you attempt to delete it. Are you sure you're actually finding a matching value?
I am just starting out C++, so sorry if this is a dumb question. I have a class Braid whose members are vectors. I have not written an assignment operator. When I do a lot of assignments to an object of the type Braid, I run into memory issues :-
0 0xb7daff89 in _int_malloc () from /lib/libc.so.6
#1 0xb7db2583 in malloc () from /lib/libc.so.6
#2 0xb7f8ac59 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#3 0x0804d05e in __gnu_cxx::new_allocator<int>::allocate (this=0xbf800204, __n=1)
at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ext/new_allocator.h:89
#4 0x0804cb0e in std::_Vector_base<int, std::allocator<int> >::_M_allocate (this=0xbf800204, __n=1)
at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/stl_vector.h:140
#5 0x0804c086 in _Vector_base (this=0xbf800204, __n=1, __a=...)
at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/stl_vector.h:113
#6 0x0804b4b7 in vector (this=0xbf800204, __x=...)
at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/stl_vector.h:242
#7 0x0804b234 in Braid (this=0xbf800204) at braid.h:13
#8 0x080495ed in Braid::cycleBraid (this=0xbf8001b4) at braid.cpp:191
#9 0x080497c6 in Braid::score (this=0xbf800298, b=...) at braid.cpp:251
#10 0x08049c46 in Braid::evaluateMove (this=0xbf800468, move=1, pos=0, depth=2, b=...)
I suspect that these memory issues are because the vectors are getting resized. What I want to know is whether objects of type Braid automatically expand when its members expand? the code I am writing is really long so I will post the section which is causing the problems. Here is the relevant section of the code :-
class Braid
{
private :
vector<int> braid; //Stores the braid.
int strands;
vector < vector<bool> > history;
vector < vector<bool> > CM;
public :
Braid () : strands(0) {}
Braid operator * (Braid);
Braid* inputBraid(int,vector<int>);
int printBraid();
int printBraid(vector<vector<int>::iterator>);
vector<int>::size_type size() const;
.....
.....
}
Here is the function which causes the issue :-
int Braid::evaluateMove(int move,int pos,int depth,Braid b)
{
int netscore = 0;
Braid curr(*this);
curr = curr.move(move,pos);
netscore += curr.score(b);
while(depth > 1)
{
netscore += curr.evaluateMove(1,0,depth,b);
netscore += curr.evaluateMove(2,0,depth,b);
for(int i = 0; i < braid.size();++i)
{
netscore += curr.evaluateMove(3,i,depth,b);
netscore += curr.evaluateMove(4,i,depth,b);
netscore += curr.evaluateMove(5,i,depth,b);
curr = curr.cycleBraid();
netscore += curr.evaluateMove(6,0,depth,b);
}
--depth;
}
return netscore;
}
Another problem :
while(depth > 1)
{
netscore += curr.evaluateMove(1,0,depth,b);
....
--depth;
}
causes endless recursion when depth >1
quick read: Braid curr(*this); causes a copy. Can't you use a pointer to the Braid?
Am I the only remarking a Stack Overflow there ?
I colored out the useless bits (for the purpose of the demo)
int Braid::evaluateMove(int move,int pos,int depth,Braid b)
{
#int netscore = 0;
#Braid curr(*this);
#curr = curr.move(move,pos);
#netscore += curr.score(b);
while(depth > 1)
{
netscore += curr.evaluateMove(1,0,depth,b);
#netscore += curr.evaluateMove(2,0,depth,b);
#for(int i = 0; i < braid.size();++i)
#{
# netscore += curr.evaluateMove(3,i,depth,b);
# netscore += curr.evaluateMove(4,i,depth,b);
# netscore += curr.evaluateMove(5,i,depth,b);
# curr = curr.cycleBraid();
# netscore += curr.evaluateMove(6,0,depth,b);
#}
--depth;
}
return netscore;
}
Now if depth is superior to 1... oups
Let's say I do:
Braid b; b.evaluateMove(1,0,2,b);
it invokes curr.evaluateMove(1,0,2,b);
which invokes curr.evaluateMove(1,0,2,b);
which ...
Well, the system might run out of memory.
Note: why does evaluateMove both copy this and ask for a copy of Braid (parameter b) ? I'd check my score method if I was you.
On an unrelated point, you probably do not want:
vector<bool>
as vector<bool> is a template specialisation which you should only use if you really, really know what you are doing. Consider vector <char> or deque<bool> instead.
What could cause this?
Here's the stack trace:
#0 0x0645c0f5 in std::_Rb_tree_increment (__x=0x83ee5b0)
at ../../../../libstdc++-v3/src/tree.cc:69
#1 0x0805409a in std::_Rb_tree_iterator<std::pair<std::string const, Widget*> >::operator++ (
this=0xbffff144)
at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:192
#2 0x08053d32 in Generic::StartLayout (this=0x8287d68) at Generic.cpp:195
#3 0x0804f6e1 in LCDControl::ConfigSetup (this=0xbffff26c) at LCDControl.cpp:91
#4 0x0804ed7c in LCDControl::Start (this=0xbffff26c, argc=1, argv=0xbffff404) at LCDControl.cpp:21
#5 0x08050964 in main (argc=1, argv=0xbffff404) at Main.cpp:11
And here's the code:
for(std::map<std::string,Widget *>::iterator w = widgets_.begin();
w != widgets_.end(); w++){
if( w->second->GetType() & WIDGET_TYPE_BAR) {
w->second->SetupChars();
}
w->second->Start();
}
Edit: This next problem is related, so I won't open a whole new question. I'll leave the answer acceptance like it is. I just need to know something. I have two iterators, one main and one within that main after a function call. They both relate to the same map. Well, the one inside gets all corrupted, and the main one's loop stops iterating.
Here's the code.
Here's StartLayout:
void Generic::StartLayout() {
Error("StartLayout: %s", key.c_str());
for(std::map<std::string,Widget *>::iterator w = widgets_.begin();
w != widgets_.end(); w++){
Error("Starting widget %s", w->first.c_str());
if( w->second->GetType() & WIDGET_TYPE_SPECIAL) {
w->second->SetupChars();
}
w->second->Start();
}
}
And here's SetupChars():
void WidgetGif::SetupChars() {
Error("SetupChars <%s> <%s>", name_.c_str(), widget_base_.c_str());
Error("Size of widgets: %d", visitor_->Widgets().size());
std::map<std::string, Widget *> widgets = visitor_->Widgets();
for(std::map<std::string, Widget *>::iterator ii=visitor_->Widgets().begin();
ii != visitor_->Widgets().end(); ii++) {
Error("<%s> Widget base %s == %s", ii->first.c_str(), ii->second->GetWidgetBase().c_str(), widget_base_.c_str());
if(ii->second->GetWidgetBase() == widget_base_ &&
((WidgetGif *)ii->second)->HasChars()) {
Error("Using chars from %s", ii->first.c_str());
for(unsigned int i = 0; i < rows_ * cols_; i++ ) {
if(i >= visitor_->GetLCDText()->CHARS) {
Error("1) GIF too large: %s, %d", name_.c_str(), visitor_->GetLCDText()->CHARS);
if(update_) delete update_;
update_ = new Property(visitor_, section_, "", new Json::Value("-1"));
return;
}
ch_[i] = ((WidgetGif *)widgets[ii->first])->GetChars()[i];
}
hasChars_ = true;
return;
}
}
// It goes on, but I snipped it here.
}
And this is what happens:
StartLayout: display_qt
Starting widget widget_gif_american_flag:layout_american_flag:0
SetupChars <widget_gif_american_flag:layout_american_flag:0> <layout_american_flag>
Size of widgets: 5
<widget_gif_american_flag:layout_american_flag:1> Widget base layout_american_flag == layout_american_flag
<widget_gif_american_flag:layout_american_flag:4> Widget base layout_american_flag == layout_american_flag
<(n
(n
��S> Widget base ГS == layout_american_flag
^C
Last edit: I figured it out. I just needed a copy of the original map for the new iterator.
There could be quite a few reasons for that. For one, it may be that GetType or SetupChars or Start do something that causes your map to change - which would invalidate the current iterator (note that using operator[] on the map, even just to read the value, is technically a mutating operation, and can cause a crash with iterator debugging enabled!). Alternatively, your map could be corrupted in memory by some code that executed before, e.g. because of a buffer overrun overwriting part of the map's tree.
You must not modify widgets_ in any of your methods GetType, SetupChars, or Start. This is most likely your problem.
If you must modify widgets_, then you will need to restart the iterator whenever such a change is made. To avoid duplicating your changes, you can use a simple marker dictionary outside the loop, or a marker member of the Widget class.