my C++ program hangs during memory deallocation.

Dear folks,

my C++ program hangs during memory deallocation.

Does anybody knows how one can find such a terrible BUG and what can
be the reason?

I know what is "memory leak", "segmentation fault", "step-on-others-toe",
but I think one of the bugs above can not hang the program.

Am I right?



How I allocate memory:

Code:

//allocate CSYMBOL vector in memory
CSYMBOL *CSYMBOL_vector(long symbLen, long symbNumb)
{
  long i=0;
  CSYMBOL *res;

  #ifdef CPP_FLAG
    res=new CSYMBOL [symbNumb];
  #else
    res=(CSYMBOL *) malloc(symbNumb*sizeof(CSYMBOL));
    if(!res)
     {
      printf("Not enough memory to allocate COMPLEX symbol\n");
      exit(1);  //terminate program if out of memory
    }
  #endif

  for(i=0;i<symbNumb;i++)
    {
    #ifdef CPP_FLAG
       res[i].x=new CPOINT [symbLen];
   #else
      res[i].x=CPOINT_vector(symbLen);
      if(!res[i].x)
       {
        printf("Not enough memory to allocate COMPLEX symbol (1)\n");
        exit(1);  //terminate program if out of memory
       }
   #endif

    res[i].symbLen=symbLen;
   }//end of  for

   return res;
}

And this is deallocation part:

Code:

//deallocate memory
long free_CSYMBOL_vector(CSYMBOL *symb2free, long symbNumb)
{
  long i=0;
  for(i=0;i<symbNumb;i++)
  if(symb2free[i].x!=NULL)
    {
     #ifdef CPP_FLAG
        delete [] symb2free[i].x;  //the program hangs here if CPP_FLAG is defined
    #else
       free(symb2free[i].x);  //or here (no CPP_FLAG)
    #endif
   }
  #ifdef CPP_FLAG
       ;  //do nothing
  #else
  else
   {
    printf("Attempt to deallocate memory which was not allocated\n");
    exit(1);
   }
  #endif

  #ifdef CPP_FLAG
    delete [] symb2free;
  #else
   free(symb2free);
  #endif
  return 0;
}

P.S. If somebody need:
gcc --version
2.95.2
---
uname -a
Linux name 2.4.20 #2 SMP Fri Feb 20 17:07:59 CET 2004 i686 unknown

Can't be sure from your code, but are you getting values for symbNum and symbLen mixed up between creation and destruction?

For example, I see you have a creator function which creates an arrary of objects of element number symbNum, where each object holds an array of CPOINT of element number symbLen. Whereas your destroyer function takes the value 'symbNum' to be the number of CPOINT elements in each object.

Just a thought...

How about deciding whether you're writing in C or C++ and ripping out the #ifdef CPP_FLAG and associated code for the language you're not interested in.

The declaration of CSYMBOL etc would be helpful as well.

Your post on the C board has been deleted. Please read the rules regarding cross-posting (like don't cross-post).

Originally posted by Davros
Can't be sure from your code, but are you getting values for symbNum and symbLen mixed up between creation and destruction?

For example, I see you have a creator function which creates an arrary of objects of element number symbNum, where each object holds an array of CPOINT of element number symbLen. Whereas your destroyer function takes the value 'symbNum' to be the number of CPOINT elements in each object.

Just a thought...

Hi,

1) If symbNumb I pass to "destructor" (pleas, let me use this incorrect name) is GREATER than I used for "constructor" I would get "segmentation fault" (or "step-no-other-toe"), but not the "hang". At least I think so...

2) If symbNumb I pass to "destructor" is LESS than I used for "constructor" some memory will not be deallocated, but still no "hang".

3) I think the "hang" is caused by something nasty hapenning outside of this two functions ("constructor", "destructor").

4) What can cause the "hang"? This is the question?

Well until you post some a complete program which compiles and crashes, its all just guesswork.

Originally posted by Salem
Well until you post some a complete program which compiles and crashes, its all just guesswork.

1) The program is big (11227 lines in *.c and *.h files) and bug can be almost everywhere;
2) 2 libraries are written in C by other people, the bug appears when we started to reuse it in our project;
3) 1st library has been connected without problems, connection of 2nd one caused "hang" for SOME input parameters;
4) We ASSUME the libraries are bug-free (tested!) => the connection causes the problem!
5) The program always hangs at the same line (deallocation of the memory), but deallocation ITSELF has been carefully tested!
6) I want to believe there are some general recommendations how to search for such a bug!

I need something like (just examples!):
- try to compile with -Wall option (doesn't help);
- assignment "int" to "unsigned int" can cause the hang (I hope it's wrong);
- do not use "char *str" and functions like "strcpy";
- something is wrong with memory (too general => I will have to check every line);
- try to use exceptions in your program (I've never used it);
- use STL (I've never used it);
- try to compile it under SUN/Windows/whatever and see the result;

Oh I see.

Well -W -Wall -ansi -pedantic -O2 make a good set of options for compiling with gcc.

Try Valgrind or Electric Fence

On my machine at least, Electric Fence came with the distribution.

So I would do something like

# compile with debug, and link in the electric fence malloc debugger
gcc -ggdb -o prog prog.c -lefence
# load the program into gdb and run it
gdb prog
run

With any luck, this will segfault at the instruction which trashes memory (use after free, step off end etc). You can then determine what the fix for it should be.

Which is better than waiting until sometime later when some malloc routine notices that memory has been trashed and then it falls over.

> res=(CSYMBOL *) malloc(symbNumb*sizeof(CSYMBOL));
Why are you casting the result of malloc?
Are by any chance compiling your 'C' code with a C++ compiler?
Did you remember to include stdlib.h? The cast masks a more serious error if you fail to include this header file.

And what is all that CPP_FLAG business all about?
It's just a confusion at the moment, and I can't see why you would ever need it.
If you want to call it from C++, there are better ways to do it, and C++ has no problem calling a 'C' function which in turns calls malloc.

> res=(CSYMBOL *) malloc(symbNumb*sizeof(CSYMBOL));
How about
grep malloc *.c | grep -v sizeof
finds all the malloc calls which don't have a sizeof() scale factor, indicating that the amount of memory allocated may be seriously shorter than what was hoped for.