Debugging corrupted memoy

[Julien Lafaye]

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.


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

[Morris Dovey]

Re: Debugging corrupted memoy

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.
>
>
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

Julien...

Why the asterisk in front of calloc?

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA

http://www.iedu.com/DeSoto/

[Eric Sosman]

Re: Debugging corrupted memoy

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.
>
>
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, if this isn't the least useful problem description
I've ever seen, it must be a close second. Values are "something
like," code resembles a "template" that has no hope of compiling,
much less running, the part that you yourself think "must be buggy"
is completely concealed ...

You say "I don't know where to start debugging this," and all
I can offer based on what you've presented is "Line forty-two."

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

That's nice. What are your hair and eye colors?

There are people here who are willing and probably able to
help you, but very few of us are mind readers. Let's see some
*actual* data (not "something like") and *actual* code (not
a "template") , and maybe we can do something. But until then ...

"Doctor, it hurts!"

"What hurts?"

"Never mind the details, just make it better!"

--
Eric Sosman
esosman@ieee-dot-org.invalid

[Jens Thoms Toerring]

Re: Debugging corrupted memoy

Julien Lafaye <sensei+usenet@ pinglou.netwrot e:

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.

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

This looks pretty wrong. First of all, what is 'obj_t'typeded' ed
to?Is it a pointer to a structure or a structure? From its use
on the right hand side it looks like it's typedef'ed as a pointer
to a structure, while the use of 'sizeof(obj_t) makes it look
like the other way round (or you would just be allocating enough
memory for a pointer and not a structure).

And then the '*' in front of the calloc() call is definitely
wrong - you don't want what the return value is pointing to
(and you would be dereferencing a void pointer, which is for-
bidden) but you want what calloc() returned stored in 'res'.
Wasn't your compiler complaining loudly or did you forgot to
ask it to report problematic code with (at least) '-W -Wall'?

And there's also the question if you included <stdlib.h-
without a prototype in scope you can get weird effects.

And, finally, you should check the return value of calloc()
before you use it;-)

// res is 0x000000..

How did you got that result? And, again, what is 'obj_t' for
a kind of type?

obj_iterate(res );
// res is 0xffffff..

Please report the exact source code you were using plus the
exact results, not something you think you remember - much
too often one is making mistakes that make figuring out the
real problem impossible.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Sean G. McLaughlin]

Re: Debugging corrupted memoy

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
}

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.

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

[Bart]

Re: Debugging corrupted memoy

On May 10, 11:02 pm, Julien Lafaye <sensei+use...@ pinglou.netwrot e:

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.
>
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

Trace the value of res in obj_iterate and see where the top half
changes...

Use printf statements or perhaps a debugger.

The cause could be anything though. Some real code posted here could
help.

--
Bartc

[Julien Lafaye]

Re: Debugging corrupted memoy

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. One 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]

Re: Debugging corrupted memoy

Jens Thoms Toerring wrote:

Julien Lafaye <sensei+usenet@ pinglou.netwrot e:

Please report the exact source code you were using plus the
exact results, not something you think you remember - much
too often one is making mistakes that make figuring out the
real problem impossible.
Regards, Jens

Sorry for the typo and the incomplete snippet. One should never try to think
about friday bugs during the week-end (actually one should never introduce
bugs on friday).
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.

JL

[Morris Dovey]

Re: Debugging corrupted memoy

Julien Lafaye wrote:

Sorry, typo in my snippet. One should read
>
obj_t *res = calloc((size_t) 1, sizeof(obj_t));

Good. Next question: Have you included stdlib.h so that no conversion
from (int) to (obj_t *)?

If so, we probably need to move on to examine fied, obj_iterate(), and
do_other_stuff( )...

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA

http://www.iedu.com/DeSoto/

[Jens Thoms Toerring]

Re: Debugging corrupted memoy

Julien Lafaye <sensei+usenet@ pinglou.netwrot e:

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. One should read

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

Ok, that look more reasonable. What about other questions
like if you have included <stdlib.hand how you did get
the value of 'res'? And what is obj_iterate() actually
doing (is it a function or a macro and why does its name
contain "iterate" when there's only one such structure)?
Finally, what is do_other_stuff( ) do or is it really
segfaulting already when called with 'res->fied' (what-
ever 'fied' is supposed to mean)?

If obj_iterate() is a function and the value of 'res' is
really changed after its call then I would speculate that
you're doing something nasty in obj_iterate() that some-
how writes over the place where 'res' is stored. And if
'obj_iterate' is a macro show us also what its doing.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Martin Ambuhl]

Re: Debugging corrupted memoy

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.

[Flash Gordon]

Re: Debugging corrupted memoy

Julien Lafaye wrote, On 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

[Willem]

Re: Debugging corrupted memoy

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
) }

Others 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 !
#EOT