Debugging corrupted memoy

Hello,

i callocated a pointer to a user-defined struct. The value of the pointer is
something like 0x0000002aaaaa (can't remember actually, I don't have the
computer running the code with me). Then I perform some stuff on the
allocated structure which must be buggy since after its execution the value
of the pointer is something like 0xffffff2aaaaa, i.e. same lsb, different
msb. I don't know where to start to debug this. , when I run the
programm I get a SIGSEGV when deferencing the pointer and valgrind shows no
indication of invalid memory access. Do you have any clue on how to start
debugging this. Below is the template of my code.


static int do_stuff()
{
obj_t res = *calloc((size_t)1, sizeof(obj_t));
// res is 0x000000
obj_iterate(res);
// res is 0xffffff
do_other_stuff(res->fied); <-- SIGSEGV
}

Julien

PS: my architecture is X86_64, Linux, gcc-4; code is compiled without
optimization, debugging symbols activated

Sean G. McLaughlin wrote:

The code is fundamentally wrong. You do not dereference the result of
calloc() and assign it to an object, but assign it to a pointer to the
object.

Sorry, typo in my snippet. should read

obj_t *res = calloc((size_t)1, sizeof(obj_t));

instead of

obj_t res = *calloc((size_t)1, sizeof(obj_t));


obj_iterate() probably and do_other_stuff() definitely expect "res" to be
a pointer, when here it isn't.

Julien Lafaye wrote:
Hello,
>
i callocated a pointer to a user-defined struct. The value of the pointer is
something like 0x0000002aaaaa (can't remember actually, I don't have the
computer running the code with me). Then I perform some stuff on the
allocated structure which must be buggy since after its execution the value
of the pointer is something like 0xffffff2aaaaa, i.e. same lsb, different
msb. I don't know where to start to debug this. , when I run the
programm I get a SIGSEGV when deferencing the pointer and valgrind shows no
indication of invalid memory access. Do you have any clue on how to start
debugging this. Below is the template of my code.

Unfortunately, the key section of your code is missing, namely, what do
you do with the pointer between the time you allocate it and free it.
Your description of the behavior (above) suggests that you are doing
ill-advised assignments of a pointer to some integer type and suffering
from sign extension, then storing the sign-extended value back into the
pointer. But your code below cannot be doing that, because you are
_not_ using calloc to store a value in a pointer.


static int do_stuff()
{
obj_t res = *calloc((size_t)1, sizeof(obj_t));

The above points to one of the problems of typing from dim memories.
res is not a pointer to obj_t but an obj_t. It is hard to imagine
scenarios in which the above has any advantage over a simple.
obj_t res;
In fact, you lose the pointer value calloc returned creating a memory leak.
Further, the above does not check that calloc succeeded before
dereferencing a possibly null pointer.

It almost always is better to avoid typenames in allocations. It may
not appear so here, where the allocation is an initializer, but use of
malloc, calloc, and realloc is more often separated from declaration.
You will find that a form like
obj_t *res = calloc(1, sizeof *res);
will do quite as well. Note that in this line res is a pointer. You
still need to check that res is not null before dereferencing it.
Note also that the cast in "(size_t)1" is nothing more than typing
exercise. Whenever you use a cast, make sure it is needed. Unneeded
casts are often incorrect casts, and the occurance of casts, while
sometimes appropriate, are more often signs of poor design or inadequate
understanding.

// res is 0x000000
^^^^^^^^
1) res almost certainly does not have any such value. res is a obj-t,
which you have told us is a struct.
2) Your comment suggests that res is all zeros. If res were a pointer,
that would be a null pointer which should not be dereferenced. Yes, I
understand that you didn't care to retype 0x0000002aaaaa from the text
above, but comments ought not be misleading.

obj_iterate(res);
// res is 0xffffff
do_other_stuff(res->fied); <-- SIGSEGV

And the above hides any other errors, but one thing is clear if you
have correctly represented your code: res is not a pointer, so res->fied
is meaningless.

}
>
Julien
>
PS: my architecture is X86_64, Linux, gcc-4; code is compiled without
optimization, debugging symbols activated

That shouldn't matter, and if it did, your post would almost certainly
be off-topic here and belong in some newsgroup for Linux, gcc, or X86.

Julien Lafaye wrote, 11/05/08 00:12:

<snip>

Nevertheless, I thought my description would recall C-masters reading this
forum a symptom of a common error committed by a newbie (like alignment pb
or unsigned to signed implicit cast). I seems that it is not the case and I
should wait two days to debug and fix this.

Q: What do you get if you multiple six by nine?

Write down all of the incorrect answers to the above question, count
them, and then you will have a rough idea of how many ways there are to
introduce a fault that fits your description.
--
Flash Gordon

Julien wrote:
) static int do_stuff()
) {
) obj_t res = *calloc((size_t)1, sizeof(obj_t));
) // res is 0x000000
) obj_iterate(res);
) // res is 0xffffff
) do_other_stuff(res->fied); <-- SIGSEGV
) }

have pointed out the problems with calloc().
Here's another two questions:
Is the prototype for obj_iterate in scope (and has it been compiled
for 64-bit pointer architecture) ?
What does obj_iterate return as value and type ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something
No I'm not paranoid. You all think I'm paranoid, don't you !
#ET