'std::bad_alloc' when working with strings

[colt]

Hello I am receiving the above error message when a method returns a string.

This is the method that fulfills the string and then return a copy of it:

string TextManager::getMtlMaterialName () {
   cout << "getMtlMaterialName" << endl;
   string mat_name;
   int i=0;
   cout << line << endl;
   while (line[i] != ' ')
      i++;
   i++;
   for (; i<line.size(); i++)
      mat_name+= line[i];
   cout << "mat_name:" <<  mat_name << endl;
   cout << "getMtlMaterialName line: " << line << endl;
   cout << "last working line" << endl;
   return mat_name;

where line is a class string variable

Here an abbreviated version of the method where the call to "getMtlMaterialName" happens

void TextManager::scanFile (Image &image, Scene &scene, int value) {
	cout << "TextManager::scanFile" << endl;
	int choice = -1;
	string mat_name;
	while (file_reader.good()) {
	   getline (file_reader,line);
	   cout << "scanFile line: " << line << endl;
		if (line == "Threads") {
		.....
                ......
                .......
    	   else if (line [0] == 'n' && line [1] == 'e') {
    	     mat_name = getMtlMaterialName ();
             getMtlData (image,scene,mat_name);
    	   }
        }
}

Some important facts:
The program runs this piece of code works several times before it crash. Only when it reach a certain line in the input file the bad_alloc happens. This is the final part of the output of my program:

getMtlMaterialName line: usemtl black
last working line
getMtlMaterialName
usemtl white
mat_name:white
getMtlMaterialName line: usemtl white
last working line
getMtlMaterialName
usemtl red
mat_name:red
getMtlMaterialName line: usemtl red
last working line
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

2)This same piece code is used in another program, however there nothing happens when using the same input file.

So, perhaps the cause of the error is not in the above code pieces. However I currently have not the slightest idea of where the cause could be. So I will deeply appreciate any suggestions of how to solve this big mess

[Albatross]

Are you sure you have enough available memory to run your program? std::bad_alloc typically gets thrown when memory can't be allocated by new.

If you should have enough memory to run said program, then it may be a good idea to check for memory leaks.

You may also be running into an issue where you'd normally have enough memory, but virtual address space fragmentation is making it impossible for your allocator to procure a continuous region of memory large enough to fit an exceedingly long string.

-Albatross

[dhayden]

It's also possible that you corrupted the heap sometime prior to getMtlMaterialName.

[ne555]

    	   else if (line [0] == 'n' && line [1] == 'e') {
    	     mat_name = getMtlMaterialName ();

¿`line' is global?
also, I don't see it starting with `ne' in your logs.

run your program through use a debugger

[colt]

Are you sure you have enough available memory to run your program? std::bad_alloc typically gets thrown when memory can't be allocated by new.

If you should have enough memory to run said program, then it may be a good idea to check for memory leaks.

You may also be running into an issue where you'd normally have enough memory, but virtual address space fragmentation is making it impossible for your allocator to procure a continuous region of memory large enough to fit an exceedingly long string.

-Albatross

I checked it and the program shows more than 600MB before closing, so it's the likely cause (should be a few MB at maximum)

`line' is global

It's a class variable.

also, I don't see it starting with `ne' in your logs.

And there isn't. Neither it should be. The call to "getMtlMaterialName" is happening from another method . I that confused myself in thinking that it should be happening from "scanFile" in this occasion. I will check it as soon as I can.

run your program through use a debugger
Well, I use GDB.

[ne555]

> run your program through use a debugger
>> Well, I use GDB.
show the backtrace
then we could see where is the exception being throw and what functions are actually called.

also, valgrind is quite good at detecting invalid access