Re: Debugging corrupted memoy
- From: Martin Ambuhl <mambuhl@xxxxxxxxxxxxx>
- Date: Sat, 10 May 2008 17:22:05 -0400
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. Obviously, 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.
.
- References:
- Debugging corrupted memoy
- From: Julien Lafaye
- Debugging corrupted memoy
- Prev by Date: Re: Debugging corrupted memoy
- Next by Date: Re: [OT] lcc first experience
- Previous by thread: Re: Debugging corrupted memoy
- Next by thread: Re: Debugging corrupted memoy
- Index(es):
Relevant Pages
|
