Thread: C Pointers Problems

  1. #1
    Registered User
    Join Date
    Oct 2006

    C Pointers Problems


    I am having very weired, and most probably very simple problems (but I am too blind to see it so far) with pointers indirection levels, memory allocation and freeing,

    things like in one file:

          mystructtype * p = NULL;
          initStruct (&p);
    then the function is:

       void initStruct (mystructtype * * p {
          (*p) = (mystructtype *) malloc(sizeof(mystructtype)); // it blows up here
            if ((*p) == NULL)
                printf ("couldn't create struct\n");
            // I do other initliazation for the structure elements, like other pointers
    and mystructtype is

       typedef struct tag_estruct  {
          long elscalar;
          unsigned long eulscalar;
          unsigned long * eularray;
        } estruct ;
        typedef struct tag_mystructtype{
          long lscalar;
          long * lpscalar;
          unsigned long ulscalar;
          unsigned long * ulparray; 
          estruct * epstruct; 
        } mystructtype;
    It is actually working in a multhreaded/multiprocess program, and I needed to test it in isolation with other things in a sequential program, but with the full data structure around it, and it is blowing up now,

    I have another similar problem, about allocating memory for an array encabsulated in dynamically allocated structure as well, this time the structure is allocated fine, but then it blows up when I allocate array of 5 integers for example, work most of the time, and then blow up with some test cases,

    for example:

       myrecType * myrec;
        myrec = (myrecType *) malloc (sizeof(myrecType));
        myrec->arrayofinterger  = NULL; // I tried removing this one, but it is still blows up
        myrec->arrayofinterger = (int *) malloc (sizeof(int) * 5); // it blows up here
    Also, so many problems with blowing up when freeing memory, I removed some of the free statements, to keep going, but I think that's why I have problems, even on smaller isolated tests, I still get these,

    I heard before about structure hacking in C, and not sure if this is related, but I can not find online references about this kind of memory allocations and passing arguments by several levels of indirection to allocate somewhere, and keep using the same memory location without copying to temporaries,

    I try on several gcc compiler, and not sure if the compiler version is what causes it, but 2 compilers now have given me these:

    gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
    gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)

    I appreciate any help I can get to sort this out, like sample code that can do similar things, or links to tutorials that describe similar functions, not basic pointers exmaples,

  2. #2
    "I Win!" by U. Lose vart's Avatar
    Join Date
    Oct 2006
    Rishon LeZion, Israel
    1. there is no need to cast malloc

    2. What do you mean by blows up?
    To be or not to be == true

  3. #3
    Registered User
    Join Date
    Jun 2005
    What do you mean when you say it "blows up"? If malloc() is just returning NULL, then that could just mean there are insufficient resources available to your program when malloc() is called.

    If the result is a crash (eg a core dump under unix) there are all sorts of possibilities. The most obvious is that some other code you haven't shown is molesting a pointer, and the crash on a malloc() call is a side-effect. You therefore need to check any code that is executed BEFORE the malloc() call.

    If the code works in a multi-threaded scenario but not in a single threaded scenario, you probably just got lucky: I would bet odds are in favour of there being something wrong in the multi-threaded scenario, but some other area of memory is being trashed so the symptom isn't visible.

    One other thing: you shouldn't need to cast the return value from malloc() with a C compiler. If you are using a C compiler, and the cast is required, you need to check if the appropriate header (<stdlib.h>) has been #include'd. Note however, that the cast will be required if your compiler is really a C++ compiler, whether <stdlib.h> is #include'd or not.

  4. #4
    Registered User
    Join Date
    Jun 2004
    no doubt about it that you have a corrupt heap.
    I think it got screwed up somewhere else thuogh, so you'll have to provide more context

  5. #5
    "I Win!" by U. Lose vart's Avatar
    Join Date
    Oct 2006
    Rishon LeZion, Israel
    Quote Originally Posted by Laserve
    no doubt about it that you have a corrupt heap.
    I think it got screwed up somewhere else thuogh, so you'll have to provide more context
    Heap can be corrupted by freeing the same memory twice, for example
    To be or not to be == true

  6. #6
    Registered User
    Join Date
    Oct 2006
    Thank you for the fast reply,

    I was trying to fix a few casting to some of the malloc I have, I didn't really finish, but around the area where it gives the error, it is still the same

    The error it gives me on gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) is:
    *** glibc detected *** ./moaLib: free(): invalid size: 0x082d1040 ***
    ======= Backtrace: =========
    ======= Memory map: ========
    0035d000-0035e000 r-xp 0035d000 00:00 0 [vdso]
    00734000-0074d000 r-xp 00000000 fd:00 1474629 /lib/
    0074d000-0074e000 r-xp 00018000 fd:00 1474629 /lib/
    0074e000-0074f000 rwxp 00019000 fd:00 1474629 /lib/
    00751000-0087e000 r-xp 00000000 fd:00 1475722 /lib/
    0087e000-00880000 r-xp 0012d000 fd:00 1475722 /lib/
    00880000-00881000 rwxp 0012f000 fd:00 1475722 /lib/
    00881000-00884000 rwxp 00881000 00:00 0
    0088c000-008af000 r-xp 00000000 fd:00 1475724 /lib/
    008af000-008b0000 r-xp 00022000 fd:00 1475724 /lib/
    008b0000-008b1000 rwxp 00023000 fd:00 1475724 /lib/
    00b9c000-00ba7000 r-xp 00000000 fd:00 1475725 /lib/
    00ba7000-00ba8000 rwxp 0000a000 fd:00 1475725 /lib/
    08048000-08056000 r-xp 00000000 fd:00 7831771 /home/mhelal/last/lib/moaLib/moaLib
    08056000-08057000 rw-p 0000d000 fd:00 7831771 /home/mhelal/last/lib/moaLib/moaLib
    082b0000-08315000 rw-p 082b0000 00:00 0
    b7e00000-b7e21000 rw-p b7e00000 00:00 0
    b7e21000-b7f00000 ---p b7e21000 00:00 0
    b7f97000-b7f98000 rw-p b7f97000 00:00 0
    b7fa5000-b7fa8000 rw-p b7fa5000 00:00 0
    bf8ef000-bf904000 rw-p bf8ef000 00:00 0 [stack]

    thank you again,


  7. #7
    "I Win!" by U. Lose vart's Avatar
    Join Date
    Oct 2006
    Rishon LeZion, Israel
    or you have a memory overrun, or some memory is freed twice
    To be or not to be == true

  8. #8
    Registered User
    Join Date
    Oct 2006
    The context would be confusing, and wouldn't help much, and this problem happens as I start running the program, and in the first complicated memory allocation (structures that contain other pointers and arrays), and passing by 2 levels of indirection like shown above.

    I make sure I free as I finish in the same scope, and allocate everytime before using in the little isolated sequential program, the problems with freeing happens in the multithreaded/multiprocess one,

    any ideas how I can trace that?

    or any other ideas about the extra levels of indirection in passing parameters, and in structures of this type,

    I appreciate your help a lot,


  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    > (*p) = (mystructtype *) malloc(sizeof(mystructtype)); // it blows up here
    Understand that memory corruption is cause and effect.

    What you're seeing here is the effect.

    The cause happened some time ago, elsewhere in your program. As such, there isn't a lot we can do without seeing the whole program. If it's a large program, we probably won't want to see it anyway.

    Here are some causes to look for
    - not allocating the right amount of memory
    -- forgetting the sizeof, getting the wrong sizeof, forgetting the count
    - overrunning the end (and sometimes the beginning) of the allocation
    - freeing the same thing twice
    - freeing something which was never allocated
    - using before allocation
    - using after free

    Since you're using Linux, you probably have valgrind and electric fence to hand as well.

    So perhaps
    gcc -g prog.c -lefence
    gdb a.out

    valgrind a.out

    Using electric fence, the debugger should trap at the first instruction which messes with allocated memory it doesn't own.
    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. sorting number
    By Leslie in forum C Programming
    Replies: 8
    Last Post: 05-20-2009, 04:23 AM
  2. problems passing pointers
    By doormat in forum C Programming
    Replies: 9
    Last Post: 04-11-2004, 04:38 PM
  3. Class Pointers
    By ventolin in forum C++ Programming
    Replies: 8
    Last Post: 04-04-2004, 06:07 PM
  4. Array of Pointers + Deleting An Object = Problems
    By Nereus in forum C++ Programming
    Replies: 3
    Last Post: 03-04-2004, 12:16 PM
  5. Request for comments
    By Prelude in forum A Brief History of
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM