By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,786 Members | 1,131 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,786 IT Pros & Developers. It's quick & easy.

Errors on parameter passing

P: n/a
Hi 'body,
I'm experiencing difficulties on parameter passing.
I wrote a library in last months, and now it crashes few times in a
month because of errors in parameter passing:
using gdb on the core dumps I can see that sometimes in function
calls, the caller passes a value and the callee receives another
value... Usually it seems to be a shifting on parameters (the callee
finds the first value stored in the second argument and so on...).
This is already strange but last time i saw a more strange thing: the
caller passes just a pointer to a structure and the callee does not
receive the pointer, it receives the value of the first element of the
structure instance!!

The above case is something like this:

struct SimpleStruct
{
void * a;
}SimpleType;

void callee(SimpleType *instance)
{
...
}

void caller()
{
SimpleType *instance=(SimpleType*)malloc(sizeof(SimpleType));
instance->a=0x123456789;
callee(instance);
}

in execution sometimes the callee crashes and using gdb i find that
callee has instance=0x123456789
How is it possible? Any idea??
Jan 8 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
frakie wrote:
I'm experiencing difficulties on parameter passing.
[Snip]
The above case is something like this:
Don't give us "something like"! Boil the problem down to the smallest
version that displays the problem, and then cut and paste that into your
posting.
>
struct SimpleStruct
{
void * a;
}SimpleType;

Did you mean to put a "typedef" in there?
void callee(SimpleType *instance)
{
...
}

void caller()
{
SimpleType *instance=(SimpleType*)malloc(sizeof(SimpleType));
The cast isn't needed, and can conceal problems.

You don't check that the malloc() worked.

Did you include "stdlib.h"?
instance->a=0x123456789;
callee(instance);
}

in execution sometimes the callee crashes and using gdb i find that
callee has instance=0x123456789
How is it possible? Any idea??
Nope, and we're working in the dark if you don't show us the real code.
Jan 8 '08 #2

P: n/a
In article <07**********************************@x69g2000hsx. googlegroups.com>,
frakie <fr*******@gmail.comwrote:
>I wrote a library in last months, and now it crashes few times in a
month because of errors in parameter passing:
We can't tell much unless you post us the real, complete code that
fails.

But one common cause of "inexplicable" errors like this is that you
don't have all your code in sync: perhaps you didn't recompile one
of the source files after changing a structure in a header, or
something like that.

-- Richard

--
:wq
Jan 8 '08 #3

P: n/a
On 8 Gen, 16:02, Mark Bluemel <mark_blue...@pobox.comwrote:
frakie wrote:
I'm experiencing difficulties on parameter passing.

[Snip]
The above case is something like this:

Don't give us "something like"! Boil the problem down to the smallest
version that displays the problem, and then cut and paste that into your
posting.
struct SimpleStruct
{
void * a;
}SimpleType;

Did you mean to put a "typedef" in there?
void callee(SimpleType *instance)
{
...
}
void caller()
{
SimpleType *instance=(SimpleType*)malloc(sizeof(SimpleType));

The cast isn't needed, and can conceal problems.

You don't check that the malloc() worked.

Did you include "stdlib.h"?
instance->a=0x123456789;
callee(instance);
}
in execution sometimes the callee crashes and using gdb i find that
callee has instance=0x123456789
How is it possible? Any idea??

Nope, and we're working in the dark if you don't show us the real code.
As i said it is a library, it's not a 2 code line program..
And the problem occurs in different function calls, not just in a
specific one, during execution so it's not a compiling issue (of
course i forgot in the example the typedef and i included the
necessary '.h').
I'll try to cut&paste a significant part of code where the error
occurs...

typedef struct struct2_s
{
long long struct2_data;
}struct2_t;

typedef struct struct1_s
{
struct2_t *info;
int size;
int length;

}struct1_t;

void size_control(struct1_t * instance)
{
if(!instance)
{
printf("Error\n");
return;
}
/* Allocating */
if(!instance->info)
{
instance->size=100;
instance->length=0;
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
}
else
{
/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
}
else
/* Increasing */
if(instance->length>=instance->size)
{
struct2_t * t=(struct2_t *)
malloc(
instance->size*10
*
sizeof(struct2_t)
);
memcpy(t, instance->info, instance-
>length*sizeof(struct2_t));
free(instance->info);
instance->info=t;
instance->size*=10;
}
else
/* Reducing */
if(instance->length+10<instance->size/10)
{
struct2_t * t=(struct2_t *)
malloc(
(instance-
>length*5)
*
sizeof(struct2_t)
);
memcpy(t, instance->info, instance-
>length*sizeof(struct2_t));
free(instance->info);
instance->info=t;
instance->size=instance->length*5;
}
}
}

void add_data(struct1_t * instance, long long data)
{
if(!instance)
return;

size_control(instance);

instance->info[instance->length].struct2_data=data;
instance->length++;
}

I think now it's simpler and readable...
Here the error occurs in memcpy because size_control doesn't receive
the instance pointer but the instance->info pointer... And i don't
know why..
Jan 8 '08 #4

P: n/a
On 8 Gen, 16:28, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <07567700-570a-4781-9a2c-cf670c667...@x69g2000hsx.googlegroups.com>,

frakie <frakie...@gmail.comwrote:
I wrote a library in last months, and now it crashes few times in a
month because of errors in parameter passing:

We can't tell much unless you post us the real, complete code that
fails.

But one common cause of "inexplicable" errors like this is that you
don't have all your code in sync: perhaps you didn't recompile one
of the source files after changing a structure in a header, or
something like that.

-- Richard

--
:wq
I don't think it is a sync issue: it occurs _sometimes_ ..
Usually that code is executed regularly and as it is expected to be
executed...
Jan 8 '08 #5

P: n/a
frakie wrote:
On 8 Gen, 16:02, Mark Bluemel <mark_blue...@pobox.comwrote:
frakie wrote:
....
How is it possible? Any idea??
Nope, and we're working in the dark if you don't show us the real code.

As i said it is a library, it's not a 2 code line program..
And the problem occurs in different function calls, not just in a
specific one, during execution so it's not a compiling issue (of
course i forgot in the example the typedef and i included the
necessary '.h').
I'll try to cut&paste a significant part of code where the error
occurs...
I didn't see any obvious problems in the code you pasted. This is to
be expected. As a general rule, if you have a problem in your program
that you don't understand, and you try to post only the part of the
program that seems to be relevant, you're usually wrong. That's the
problem with posting incomplete code.

It would be nice if you could trim this down to a 2-line program, but
no one is asking you to. What you should do is first create a program
that reliably reproduces the problem, 100% of the time. Then, simplify
that program as much as possible, while still reliably reproducing the
problem. In the course of trimming it down, there's a good chance that
you'll figure out what the problem is. If not, post the COMPLETE
program, no matter how long it is.

If it depends upon an input file, include the input file. However,
unless you have a problem with the I/O routines which read that file,
it's generally better, to simplify your code which reads the file by
replacing it with code which initializes data with the values that it
would have had after reading the input file.

Jan 8 '08 #6

P: n/a
frakie wrote:
[...]
/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
Are you sure malloc(0) is what you intended to do?

--
Er*********@sun.com
Jan 8 '08 #7

P: n/a
In article
<73**********************************@e25g2000prg. googlegroups.com>,
frakie <fr*******@gmail.comwrote:

<snip>

I notice that you never check to see that malloc() didn't fail. That
could cause all sorts of odd behavior.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 8 '08 #8

P: n/a
Eric Sosman wrote:
frakie wrote:
>[...]
/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);

Are you sure malloc(0) is what you intended to do?
And if you do, are you aware that this is causeing implementation defined
behavoir?
malloc(0) is allowed to either return NULL or a (non NULL) pointer to 0
bytes.
What behavoir does your implementation define here?

Bye, Jojo
Jan 9 '08 #9

P: n/a
On 9 Gen, 08:10, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
Eric Sosman wrote:
frakie wrote:
[...]
/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
Are you sure malloc(0) is what you intended to do?

And if you do, are you aware that this is causeing implementation defined
behavoir?
malloc(0) is allowed to either return NULL or a (non NULL) pointer to 0
bytes.
What behavoir does your implementation define here?

Bye, Jojo
D'oh!
That's what happens doing cut&paste...
That was intended to be

/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->size=100;
instance->length=0;
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
}

I know it is nearly impossible to find out the effective error from a
scratch...
I don't know when and how it happens, I know only where (in the code),
that's why i need effort to resolve it:
the library input is a highly preprocessed DVBH stream received from a
DVBH decoder and this means that i cannot reproduce error cases.
I'm sorry, I don't want to waste your time any more.
Do you know a general reason that could cause a problem like the one i
posted (excluding the loss of sync on code compilation)?
Is it possible that a unauthorized (accidental) access to code memory
heap could modify argument information in the call stack?
Jan 9 '08 #10

P: n/a
On 9 Gen, 08:10, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
Eric Sosman wrote:
frakie wrote:
[...]
/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
Are you sure malloc(0) is what you intended to do?

And if you do, are you aware that this is causeing implementation defined
behavoir?
malloc(0) is allowed to either return NULL or a (non NULL) pointer to 0
bytes.
What behavoir does your implementation define here?

Bye, Jojo
D'oh!
That's what happens doing cut&paste...
That was intended to be

/* Reallocating */
if(instance->size==0)
{
free(instance->info);
instance->size=100;
instance->length=0;
instance->info=(struct2_t *)
malloc(
instance->size
*
sizeof(struct2_t)
);
}

I know it is nearly impossible to find out the effective error from a
scratch...
I don't know when and how it happens, I know only where (in the code),
that's why i need effort to resolve it:
the library input is a highly preprocessed DVBH stream received from a
DVBH decoder and this means i cannot reproduce error cases.
I'm sorry, I don't want to waste your time any more.
Do you know a general reason that could cause a problem like the one i
posted (excluding the loss of sync on code compilation)?
Is possible a code memory heap unauthorized (accidental) access to
modify argument information in the call stack?
Jan 9 '08 #11

P: n/a
In article <f4**********************************@n20g2000hsh. googlegroups.com>,
frakie <fr*******@gmail.comwrote:
>Do you know a general reason that could cause a problem like the one i
posted (excluding the loss of sync on code compilation)?
Yes, any kind of memory corruption.

Try running your program under a memory checker such as valgrind.

-- Richard
--
:wq
Jan 9 '08 #12

P: n/a
On 9 Gen, 10:46, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <f4fb4327-d18e-48d5-836e-ef52cb6fc...@n20g2000hsh.googlegroups.com>,

frakie <frakie...@gmail.comwrote:
Do you know a general reason that could cause a problem like the one i
posted (excluding the loss of sync on code compilation)?

Yes, any kind of memory corruption.

Try running your program under a memory checker such as valgrind.

-- Richard
--
:wq
Wow it seems to be the first really working memory checker..
Thank you a lot!!
Jan 9 '08 #13

P: n/a
frakie wrote:
rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
>frakie <frakie...@gmail.comwrote:
>>Do you know a general reason that could cause a problem like the
one i posted (excluding the loss of sync on code compilation)?

Yes, any kind of memory corruption.

Try running your program under a memory checker such as valgrind.

Wow it seems to be the first really working memory checker..
Try the malldbg package in nmalloc.zip (for DJGPP)

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 9 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.