error when return 0; in int main()w

[elninio]

I get the following error, but only when I return 0:

*** glibc detected *** entropy: double free or corruption (!prev): 0x08775e10 ***

no error will pop up until my main function returns 0. From my research this is an error that you get when the program is having trouble deallocating memory. I am using some vectors in my main function, but I'm not sure if it can be due to that. I made sure to clear clear all my vectors before the end of the program but that didn't do the trick. I'm sofa king confused!!

[brewbuck]

I get the following error, but only when I return 0:

*** glibc detected *** entropy: double free or corruption (!prev): 0x08775e10 ***

no error will pop up until my main function returns 0. From my research this is an error that you get when the program is having trouble deallocating memory. I am using some vectors in my main function, but I'm not sure if it can be due to that. I made sure to clear clear all my vectors before the end of the program but that didn't do the trick. I'm sofa king confused!!

Even if clearing the vectors made the error go away, it would not resolve the problem. You are corrupting the heap in some manner. Are you dynamically allocating memory, or only using vectors? Either way, you are accessing (writing to) memory beyond limits somewhere.

[elninio]

Even if clearing the vectors made the error go away, it would not resolve the problem. You are corrupting the heap in some manner. Are you dynamically allocating memory, or only using vectors? Either way, you are accessing (writing to) memory beyond limits somewhere.

I've tried dyamicall, then I've tried setting a vector size, and resizing the vector everytime the loop starts; something like this.

for(
vect.resize()
for (
vect[i]++
)
vect.clear()
)

[matsp]

You propably have to post the REAL code, not some "something like this" - "something like this" is fine for explaining how something should be done, but when it comes to bug-finding, it is often subtle details that are causing the problem, not the overall approach (although that is of course also a potential problem).

--
Mats

[CornedBee]

Not Linux-specific, moving.

[elninio]

map<string, int> Fmap;
vector<map<string,int> > kFmap;

cout << "... Indexing feature-values ... ";
for (unsigned int k = 0; k < spec.features.size(); k++){
  //Fmap.resize(spec.features.size());
  for (int i = 3; i <= argc; i++){
    dataset_loader loader(argv[i]);
    Fmap[namesmap[i]] = spec.features[k].load(loader);
  }
  kFmap[k] = Fmap;
  Fmap.empty();
}
cout << "OK" << endl;

this one gave a seg fault

have also tried:

map<string, int> Fmap;
vector<map<string,int> > kFmap;

cout << "... Indexing feature-values ... ";
for (unsigned int k = 0; k < spec.features.size(); k++){
  //Fmap.resize(spec.features.size());
  for (int i = 3; i <= argc; i++){
    dataset_loader loader(argv[i]);
    Fmap[namesmap[i]] = spec.features[k].load(loader);
  }
  kFmap.push_back(Fmap);
  Fmap.empty();
}
cout << "OK" << endl;

this one worked, but I'm afraid it has been done incorrectly, because after I execute a similar loop following this, my program breaks RIGHT AFTER the "cout << "OK" << endl; of the 2nd block of code posted ABOVE. Here is the THIRD block of code that follows the SECOND (the FIRST is no longer in the picture):

[

// Index P(F) matrices
cout << "... Indexing P(F) matrices ...";
vector<vector<int> > kF;
vector<int> F;
for (unsigned int k = 0; k < spec.features.size(); k++){
  F.resize(spec.features[k].max_val());
  for (int i = 3; i <= argc; i++){ 
    F[kFmap[k][namesmap[i]]]++;
  }
  kF.push_back(F);
  F.clear();
  cout << "k = " << k << endl;
}
cout << "OK" << endl;
	
for (unsigned int i = 0; i < kF.size(); i++){
  for (unsigned int j = 0; j < kF[i].size(); j++){
    cout << kF[i][j] << " ";
  }
  cout << endl;
}

for this part of code, the program runs all of this code, but then gives me the *** glibc detected *** entropy: free(): invalid next size (normal): 0x0875ccb0 *** error. When i remove

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

from code the third code block, it runs about halfway (k = 32, but k=53 normally), and gives *** glibc detected *** entropy: munmap_chunk(): invalid pointer: 0x08752d88 ***

[Salem]

A couple of tools
http://valgrind.org/
http://www.perens.com/works/software/ElectricFence/

For example, if you link with the electric fence library, and run the result in the debugger, it should trap at the point you trash memory.

[elninio]

A couple of tools
http://valgrind.org/
http://www.perens.com/works/software/ElectricFence/

For example, if you link with the electric fence library, and run the result in the debugger, it should trap at the point you trash memory.

thanks, which do you recommend? I'll try both but I'd like to hear your thoughts on them.

[elninio]

http://cboard.cprogramming.com/showthread.php?t=107143

after consulting this thread, does the same case apply in my situation? I am not sure if the error is from trying to deallocate memory that has already been deallocated, or trying to acccess deallocated memory, or trying to access memory reserved by other programs

[Elysia]

The problem is simply undefined behavior. Most likely you are thrashing memory, as pointed out.
These tools will help you locate such things, memory errors.
I can also recommend using Visual Studio's debugger. By default, it tends to trap some common errors such as writing beyond the end of an array (or you can use use the vector's at method).

[anon]

One thing that stands out is loops like this:

for (int i = 3; i <= argc; i++)

If I'm not mistaken that would normally loop for one more argv than there is, passing NULL somewhere that might not expect it and/or i might get out of bounds for something.

[elninio]

One thing that stands out is loops like this:

for (int i = 3; i <= argc; i++)

If I'm not mistaken that would normally loop for one more argv than there is, passing NULL somewhere that might not expect it and/or i might get out of bounds for something.

argc is the number of arguments including the exe name. my file runs like this:

filename specfile specfile file1 file 2 file 3... file n.

therefore argc = n+3 , so i start at int i = 3, that is file 1.

[elninio]

argc is the number of arguments including the exe name. my file runs like this:

filename specfile specfile file1 file 2 file 3... file n.

therefore argc = n+3 , so i start at int i = 3, that is file 1.

also i think if i was accessing an element that i was supposed to, wouldn't it give me seg faults instead of gtklib errors?

[laserlight]

anon is concerned about the loop condition, not the initial value of i. argv[argc] is a null pointer, so on the last iteration of the loop, accessing argv[i] would access argv[argc], which may not be what you intend. To avoid this, change the loop condition to i < argc.

[elninio]

anon is concerned about the loop condition, not the initial value of i. argv[argc] is a null pointer, so on the last iteration of the loop, accessing argv[i] would access argv[argc], which may not be what you intend. To avoid this, change the loop condition to i < argc.

wouldn't this not process the last file I pass as parameter? thats what i was refering to in my reply.