error when return 0; in int main()w

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!!

Quote:

---

Originally Posted by 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!!

---

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.

Quote:

---

Originally Posted by brewbuck

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()
)

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

Not Linux-specific, moving.

Code:

---


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:

Code:

---


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):

[

Code:

---


// 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

Code:

---

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 ***

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.

Quote:

---

Originally Posted by 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.

---

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

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

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).

One thing that stands out is loops like this:

Code:

---

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.

Quote:

---

Originally Posted by anon

One thing that stands out is loops like this:

Code:

---

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.

Quote:

---

Originally Posted by 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?

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.

Quote:

---

Originally Posted by 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.

---

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

Here is the report from valgrind:

Code:

---


==9371== Invalid read of size 4
==9371==    at 0x8050C4A: main (entropy.cpp:105)
==9371==  Address 0x4a150f4 is 0 bytes after a block of size 396 alloc'd
==9371==    at 0x4024025: operator new(unsigned) (vg_replace_malloc.c:224)
==9371==    by 0x8055723: std::vector<int, std::allocator<int> >::_M_fill_insert(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, unsigned, int const&) (new_allocator.h:91)
==9371==    by 0x8050B09: main (stl_vector.h:653)
k = 29
k = 30
k = 31
k = 32
k = 33
k = 34
k = 35
k = 36
k = 37
k = 38
k = 39
k = 40
k = 41
k = 42
k = 43
k = 44
k = 45
k = 46
k = 47
k = 48
k = 49
k = 50
k = 51
k = 52
OK
P(F,C) done
==9371==
==9371== ERROR SUMMARY: 224 errors from 1 contexts (suppressed: 28 from 1)
==9371== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9371== malloc/free: 707,923 allocs, 707,923 frees, 2,107,823,781 bytes allocated.
==9371== For counts of detected errors, rerun with: -v
==9371== All heap blocks were freed -- no leaks are possible.
mockset #
mockset # valgrind --leak-check=yes entropy spec.json x3-truth-map.txt *h5 -v
==9374== Memcheck, a memory error detector.
==9374== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9374== Using LibVEX rev 1854, a library for dynamic binary translation.
==9374== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9374== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==9374== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9374== For more details, rerun with: -v
==9374==
... Indexing truthmap ... OK
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::resize
... Indexing filenames ... ==9374==
==9374== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1)
==9374== malloc/free: in use at exit: 791,127 bytes in 21,938 blocks.
==9374== malloc/free: 133,693 allocs, 111,755 frees, 9,435,638 bytes allocated.
==9374== For counts of detected errors, rerun with: -v
==9374== searching for pointers to 21,938 not-freed blocks.
==9374== checked 988,264 bytes.
==9374==
==9374== 5,820 bytes in 116 blocks are possibly lost in loss record 26 of 31
==9374==    at 0x40237F9: malloc (vg_replace_malloc.c:207)
==9374==    by 0x40F6474: H5FL_malloc (in /prog/lib/hdf5-1.8.1/hdf5/lib/libhdf5.so.5.0.1)
==9374==
==9374==
==9374== 386,444 bytes in 9,887 blocks are possibly lost in loss record 31 of 31
==9374==    at 0x4024025: operator new(unsigned) (vg_replace_malloc.c:224)
==9374==    by 0x43519F0: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.9)
==9374==    by 0x4352CF4: (within /usr/lib/libstdc++.so.6.0.9)
==9374==    by 0x4352EA6: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.9)
==9374==    by 0x808449C: __static_initialization_and_destruction_0(int, int) (in /prog/igor/src/entropy/entropy)
==9374==    by 0x8084504: _GLOBAL__I__ZN2H59Exception11DEFAULT_MSGE (in /prog/igor/src/entropy/entropy)
==9374==    by 0x80A2DB4: (within /prog/igor/src/entropy/entropy)
==9374==    by 0x804E24B: (within /prog/igor/src/entropy/entropy)
==9374==    by 0x80A2D58: __libc_csu_init (in /prog/igor/src/entropy/entropy)
==9374==    by 0x4446330: (below main) (in /lib/libc-2.7.so)
==9374==
==9374== LEAK SUMMARY:
==9374==    definitely lost: 0 bytes in 0 blocks.
==9374==      possibly lost: 392,264 bytes in 10,003 blocks.
==9374==    still reachable: 398,863 bytes in 11,935 blocks.
==9374==        suppressed: 0 bytes in 0 blocks.
==9374== Reachable blocks (those to which a pointer was found) are not shown.
==9374== To see them, rerun with: --leak-check=full --show-reachable=yes

---

Quote:

---

Originally Posted by elninio

Code:

---


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:

Code:

---


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):

[

Code:

---


// 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

Code:

---

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 ***

---

could this be the problem right here: F[kFmap[k][namesmap[i]]]++; (this is in the 3rd block of code i posted)

I'm assuming that when a vector is resized, its entries are initialized to zero? Is this not the case

AHHHH! *throws chair*

ok this was the problem:

F.resize(spec.features[k].max_val()); i changed it to ...max_val() + 1)

i guess its true, off by one errors are the most common!

Quote:

---

Originally Posted by elninio

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

---

No, the last filename would be at argv[argc-1], assuming argc > 3 (argc <= 3 implies no filenames were provided).

Quote:

---

Fmap.empty();

---

This function doesn't do what you think it does. You're looking for clear().