"Error in ... free(): invalid next size (normal):... Aborted (core dumped)""

[hyperfine]

Hello,

I'm having an issue with this program that's really bothering me. The code runs fine and goes to completion, but I get the error that's in the post title. I'm familiar with core-dump-type errors; usually caused by trying to access memory that is out-of-bounds. This doesn't seem to be that type of error, because my only dynamic memory allocation is in a single vector and I erase all of its elements using .erase() at the end of the program. The only other thing I can think of is that my file uses ifstream/ofstream inputs/outputs. I close them at the end of the file, but maybe that could be the issue? Anyways, I've commented out closing them and the issue still isn't fixed.

Here's a relevant snippet of the code, I can post more if needed. Note that the error is given to me after or right before the return call from int main()... I really don't know what to make of that.

int main( )
{
  //Establish and open input file
  string FileIn = "410nm_0002.atf";
  string FileOut = "out";
  //FileIn = GetFileIn( );
  string Directory = "/home/";
  FileIn = Directory + FileIn;
  
  FileIn_f.open( FileIn.c_str( ) );
  FileOut_f.open( FileOut.c_str( ) );
  
  block.resize( blocklength );   //Num bytes in memblock
  
  //Main loop
  if( FileIn_f.is_open( ) )                        
    {   
 
      FindTotalLines( FileIn );
      
      ClearHeader( );

      FindEvents( );

      DeallocateMemory( );

      FileIn_f.close();  
      FileOut_f.close();

    }
  else
    {
      cout << "Couldn't open input file\n";
    }


  return 0;

}

void DeallocateMemory( )
{
  for( int i = 0; i < blocklength; i++ )
    {
      block.erase(block.begin());
    }

  cout << "block size: " << block.size() << "\n\n";
  
}

[MiiNiPaa]

for( int i = 0; i < blocklength; i++ )  {
      block.erase(block.begin());
}

Are you trying to win contest "slowest container clearing"? Why not use .clear() member function? Or even just let vector destructor do its job?

Nevertheless, problem is probably caused that you messed with one of the object memory (buffer overflow ir something similar) and now when its destructor invoked, it tries to free wrong memory.

Try to run your program through debugger and look where exactly it fails.

[LB]

You have not shown enough code to isolate the problem.

[hyperfine]

Thanks for the replies, guys.

Are you trying to win contest "slowest container clearing"? Why not use .clear() member function? Or even just let vector destructor do its job?

I'll be honest, while I like to think I've gotten good at programming in the past few months of self-teaching I still have HUGE gaps in my knowledge from a lack of formal training. Regardless, I originally had block.clear() in my code but I found this info about the function:

A reallocation is not guaranteed to happen, and the vector capacity is not guaranteed to change due to calling this function.

So, I thought that might be the issue and changed up the way I was clearing the vector just to eliminate the possibility that that was the issue.

Nevertheless, problem is probably caused that you messed with one of the object memory (buffer overflow ir something similar) and now when its destructor invoked, it tries to free wrong memory.

Sorry, not quite sure I understand this. Could the buffer flow you refer to be the buffer from an ifstream/ofstream?

I'll run a debugger and try to pinpoint the exact location of the error. I'll step it through gdb and come back.

[MiiNiPaa]

So, I thought that might be the issue and changed up the way I was clearing the vector just to eliminate the possibility that that was the issue.

Actually after erase reallocation will not happen too (for sure this time) and capacity will not change.

If your code is not really big (under 300 lines) you can post it here.

[hyperfine]

From the debugger:

Breakpoint 2, main () at eventfinder.cpp:122
122 FileIn_f.close();
(gdb) step
123 FileOut_f.close();
(gdb) step
*** Error in `/home/preston/Desktop/Science/Research/ClampAnalyze/eventfinder/eventfinder': free(): invalid next size (normal): 0x0000000000608620 ***

Program received signal SIGABRT, Aborted.
0x00007ffff722abb9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)

The error occurs after all the meaningful parts of my code... Basically, like I said in my first post, it occurs when return 0; is called in int main().

[hyperfine]

Hi MiiNiPaa, thanks for sticking with me.

The code is ~450 lines. I wouldn't want to do that to you. Still, as I mentioned in my previous post the error occurs at the very end of the program. It seems unlikely to me that something deep in the interior of the program could produce an error at the end of the code, especially considering the code compiles and runs perfectly except for that memory error.

EDIT: I also ran the program through valgrind and it found no memory leaks, and no other suspicious errors were posted.

[MiiNiPaa]

Still, post it to the any paste site. Like http://pastebin.com/
It is not that big and I really need only to check on which destructor crashes.
Example of input file will be nice too.

It seems unlikely to me that something deep in the interior of the program could produce an error at the end of the code

It is very likely that violated invariants will not show themselves until object destruction.

[hyperfine]

link to code: http://pastebin.com/hTN9s6iW

I can't post an entire sample of an input data file, because they are ~100 mb data text files. Here's the general format, though:

ATF 1.0
7 4
"AcquisitionMode=Gap Free"
"Comment="
"YTop=200000,200000,10"
"YBottom=-200000,-200000,-10"
"SweepStartTimesMS=0.000"
"SignalsExported=IN 0,IN 4,IN 5"
"Signals=" "IN 0" "IN 4" "IN 5"
"Time (s)" "Trace #1 (pA)" "Trace #1 (pA)" "Trace #1 (V)"
0 -12.207 -30322.3 0.298462
1e-4 0 -30334.5 0.297852
2e-4 0 -30334.5 0.296936
3e-4 -18.3105 -30334.5 0.297546
4e-4 -18.3105 -30328.4 0.296936
5e-4 -6.10352 -30346.7 0.297852
6e-4 -18.3105 -30328.4 0.297241
7e-4 -24.4141 -30340.6 0.297852

[MiiNiPaa]

I cannot reproduce your problem, but if this code ever gains control:

      //This is used to kill false-events
      if( i > blocklength )
	{
	  FillBlock( i ); //Should be i - blocklength + (jumpahead) ?
	  return;
	}

Then this: block[i + blocklength - blockstart] = ReadRow( ); will write before actual vector buffer, potentually wrecking vector internals. (I actually was able to reproduce it by manually writing garbage before vector).

Try to replace all index accesses (block[something]) with checked access (block.at(something)) If it will throw an exception, then this is the problem.

[hyperfine]

Ok I'll look into it. Thanks for taking a look!