Thread: my C++ program hangs during memory deallocation.

  1. #1
    Registered User
    Join Date
    Mar 2004
    Posts
    3

    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

  2. #2
    Code Monkey Davros's Avatar
    Join Date
    Jun 2002
    Posts
    812
    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...
    OS: Windows XP
    Compilers: MinGW (Code::Blocks), BCB 5

    BigAngryDog.com

  3. #3
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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).
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  4. #4
    Registered User
    Join Date
    Mar 2004
    Posts
    3
    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?

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well until you post some a complete program which compiles and crashes, its all just guesswork.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User
    Join Date
    Mar 2004
    Posts
    3
    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;
    Last edited by the-tzar; 03-06-2004 at 10:15 AM.

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Mutex and Shared Memory Segment Questions.
    By MadDog in forum Linux Programming
    Replies: 14
    Last Post: 06-20-2010, 04:04 AM
  2. Replies: 7
    Last Post: 02-06-2009, 12:27 PM
  3. Replies: 8
    Last Post: 04-12-2007, 12:42 PM
  4. Pointer's
    By xlordt in forum C Programming
    Replies: 13
    Last Post: 10-14-2003, 02:15 PM