I have a BAD_ACCESS issue in scenario where I think a bad access doesn’t make any sense.
I have a map of strings. It is filled using the return value of a separate function. The map is then sent as argument to other functions. When I reach the return statement of the function, the application crashes.
I entered the debugger to see what happens in the memory, it looks perfectly normal (I have the values I would expect); If I try to clear the map before I reach the return statement, I have the exact same error on the clear instruction. This leads me to believe that the issue is actually in the string destruction, but I am really speculating here.
Here is a sample of code to give you an idea of what I do (I cannot give you access to the actual code…) :
bool funct() {
std::map<std::string, std::string> itemList = getList();
// std::map<std::string, std::string> copy = itemList; // tried copying the list content
itemList[“aKey”] = “value”;
ItemSelectionPopup myPopup(itemList);
myPopup.showPoppup();
// itemList.clear(); // tested clearing the itemList, it will crash here for BAD_ACCESS
return true; // BAD_ACCESS
}
I also found that moving this code from my function to the calling code, and moving itemList’s declaration from here to the top of the calling code (C style) solves the issue… sometimes… (depending on where exactly I declare it, and maybe also of my luck…)
My assumptions:
- When my map is filled, all the strings are copied into the local map, getting their own memory space in the stack
- this memory space is automatically allocated by the std::map
- the memory space will automatically be freed by the destructors on exiting the function, and not before (Debug or Release)
Some points that might matter:
- this runs in a boost::thread, including the calling function
- those variables are not accessed from the outside of the thread
- myPopup.showPoppup show a modal NSAlert and only returns when the alert is validated/canceled
- The same code works fine on Windows (except using a native windows view instead of an NSAlert)
Are only of my assumptions wrong? Is there any reason why this issue would appear?
I am running on Mac OS X 10.10.2, and I am using the OS X 10.9 SDK. I use C++11 with the libstdc++ (CNU C++ standard library).
I would like to add a screenshot but cannot yet, so you will have to believe me when I say the crash happens in stl_tree.h on this line (~512):
static _Link_type
_S_right(_Base_ptr __x)
{ return static_cast<_Link_type>(__x->_M_right); }
Thanks in advance,
J-O
Aucun commentaire:
Enregistrer un commentaire