0

I have a vector with a list of commands as shown below:

//COMMAND INITIALISATION
 std::vector<std::string> objectInitialisationAction;
 objectInitialisationAction.push_back("CREATE");              //0
 objectInitialisationAction.push_back("END_CREATE");          //1       
 objectInitialisationAction.push_back("START_TIMELINE");      //2

I only access this vector by using my function shown below:

int SearchFor(std::string search, std::vector<std::string> from)
{
int result=-1;
for(int i=0; i<from.size(); i++)
if(from[i]==search)
{
     result=i;
     break;
}
if(result == -1)
{
   std::ofstream error("searching.txt");
   error<<"search failed, original value = \""<<search<<"\""<<std::endl;
   error<<"values in the table:"<<std::endl;
   for(int i=0; i<from.size();i++)
   error<<"value "<<i<<": "<<from[i]<<std::endl;
   error.close();
}

return result;
}

With only one function call:

commandNum=SearchFor(command[0], objectInitialisationAction);

This is the only place where I access the vector, yet when I call the function for the nth time (it always brakes at the same point in the code) it accesses wrong and outputs gibberish. Some of the code I list below:

    search failed, original value = "CREATE"
    values in the table:
    value 0: CREATE      Øç¼   Œ                      Ôç¼   Œ                      Ðç¼              Exit               ¼ç¼          ¸ç¼   Œ      p«üxðù   ;    ´ç¼   Œ      pëù@òø  €<    °ç¼   ŒBerlin Sans FB Demi e   ¬ç¼   ˆ°¿^nmra     œç¼   ŒBerlin Sans FB Demi e   ˜ç¼             help        ”ç¼   ˆ          object_dump ç¼             test        Œç¼   Ž          spawn       ˆç¼   ‹          load_map    „ç¼   Ž
//and so on...   

Any suggestions as to why a vector may corrupt like that?

4
  • 3
    Your code looks correct to me. In this case, there should be another part of your application that corrupts the memory, e.g. by accessing invalid pointers. Commented Mar 7, 2014 at 10:29
  • @anderas By invalid pointers do you mean pointers to some other values that are unrelated to this vector but access the same memory as the vector? Commented Mar 7, 2014 at 10:59
  • Right. For example, there could be an out-of-range array access, a dangling pointer or a use-after-delete somewhere. Tools like Valgrind might help you here. Commented Mar 7, 2014 at 11:04
  • @anderas Thank you, you're most likely correct as I handle a lot of pointers in my program. Also that would explain some other issues with my program. If you want, you can post your comment as an answer so I can accept it. Commented Mar 7, 2014 at 11:09

4 Answers 4

2

It seems all correct. Compile and execute this. If it is all correct probably the problem is in another part of your code.

#include <iostream>
#include <vector>
#include <fstream>

using namespace std;


int SearchFor(std::string search, std::vector<std::string> from)
{
    int result=-1;
    for(unsigned int i=0; i<from.size(); i++)
        if(from[i]==search)
        {
            result=i;
            break;
        }
    if(result == -1)
    {
        std::ofstream error("searching.txt");
        error<<"search failed, original value = \""<<search<<"\""<<std::endl;
        error<<"values in the table:"<<std::endl;
        for(unsigned int i=0; i<from.size(); i++)
            error<<"value "<<i<<": "<<from[i]<<std::endl;
        error.close();
    }

    return result;
}

int main()
{

    std::vector<std::string> objectInitialisationAction;
    objectInitialisationAction.push_back("CREATE");              //0
    objectInitialisationAction.push_back("END_CREATE");          //1
    objectInitialisationAction.push_back("START_TIMELINE");      //2

    for(unsigned int i=0; i<objectInitialisationAction.size(); i++)
    {
        cout<< objectInitialisationAction[i] << endl;
    }

    cout << "FOUND " << SearchFor("CREATE", objectInitialisationAction);

    return 0;
}

I suggest you to add using namespace std; at the beginning of the file, so you have not to add std::blablabla on each declaration...your code will be more readable :) and please....INDENT IT :)

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

Comments

1

Your code looks correct to me. In this case, there should be another part of your application that corrupts the memory. For example, there could be an out-of-range array access, a dangling pointer or a use-after-delete somewhere. Tools like Valgrind might help you here.

Comments

0

The code looks ok as it is. The most likely scenario for me is that the length field of your strings gets unintentionally overwritten, because the command, i.e. the actual data, is still there. It's just that the string thinks it's longer than that. (Overwriting the characters wouldn't lead to the output you report: The commands would be overwritten, but the string length would still be short.) Overwriting memory typically happens through an array index or pointer which is out of bounds. The data it points to must have the same linkage as the strings (in your example local or global/static).

One strategy for bug searching would be to occasionally print the length of objectInitialisationAction's element strings; if they are too long you know something went wrong.

It may help to comment out code using a kind of binary search strategy (comment out one half -- mocking it's functionality to keep the prog running -- and look whether the error still occurs, then divide the faulty part again etc.).

Note that you pass the vector by value into SearchFor() which is perhaps unintended. The corruption may happen at the caller's or callee's side which should be easy to test.--

Hoped that helped.

Comments

-1

try to pass all params through const refs:

int SearchFor(const std::string& search, const std::vector<std::string>& from)
{
 ...
}

2 Comments

While this is generally a good suggestion, it does not have to do with the problem. (See gior91's answer.)
iam agree, but this suggestion exclude possible codes problems in the future

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.