C Pointers Problems

Hi

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:

Code:

---

      mystructtype * p = NULL;
      initStruct (&p);

---

then the function is:

Code:

---

  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

Code:

---

  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:

Code:

---

  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,

1. there is no need to cast malloc
http://faq.cprogramming.com/cgi-bin/...&id=1043284351

2. What do you mean by blows up?

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.

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

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

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: =========
/lib/libc.so.6[0x7b4a68]
/lib/libc.so.6[0x7b57f5]
/lib/libc.so.6(malloc+0x73)[0x7b67f4]
./moaLib[0x8051c18]
./moaLib[0x804a5d2]
./moaLib[0x8053718]
./moaLib[0x8048ec4]
./moaLib[0x804a3e1]
/lib/libc.so.6(__libc_start_main+0xdc)[0x7664e4]
./moaLib[0x8048981]
======= Memory map: ========
0035d000-0035e000 r-xp 0035d000 00:00 0 [vdso]
00734000-0074d000 r-xp 00000000 fd:00 1474629 /lib/ld-2.4.so
0074d000-0074e000 r-xp 00018000 fd:00 1474629 /lib/ld-2.4.so
0074e000-0074f000 rwxp 00019000 fd:00 1474629 /lib/ld-2.4.so
00751000-0087e000 r-xp 00000000 fd:00 1475722 /lib/libc-2.4.so
0087e000-00880000 r-xp 0012d000 fd:00 1475722 /lib/libc-2.4.so
00880000-00881000 rwxp 0012f000 fd:00 1475722 /lib/libc-2.4.so
00881000-00884000 rwxp 00881000 00:00 0
0088c000-008af000 r-xp 00000000 fd:00 1475724 /lib/libm-2.4.so
008af000-008b0000 r-xp 00022000 fd:00 1475724 /lib/libm-2.4.so
008b0000-008b1000 rwxp 00023000 fd:00 1475724 /lib/libm-2.4.so
00b9c000-00ba7000 r-xp 00000000 fd:00 1475725 /lib/libgcc_s-4.1.1-20060525.so.1
00ba7000-00ba8000 rwxp 0000a000 fd:00 1475725 /lib/libgcc_s-4.1.1-20060525.so.1
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]
Aborted

thank you again,

Manal

or you have a memory overrun, or some memory is freed twice

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,

thanks,

> (*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
run

Or
valgrind a.out

Using electric fence, the debugger should trap at the first instruction which messes with allocated memory it doesn't own.