Run-Time Check Failure #2 for char * variable

[Erroneous Seth]

Hello to everyone,

I am having this problem with the following code:

typedef struct test
{
	int  i;
	char c[50];
} testStruct;

int main()
{
	char *pData;
	testStruct t;

	t.i = 5;
	strcpy_s(t.c, 50*sizeof(char), "hello");

	pData = (char *)malloc(sizeof(t));
	memcpy(&pData, &t, sizeof(t));
	
	testStruct a;
	memcpy(&a, &pData, sizeof(t));

	cout << a.i << ' ' << a.c << endl;

	system("PAUSE");
	return (0);
}

The problem occurs with the variable "pData", the moment the program returns.

Could someone, please, indicate to me what the problem to the above source code is?

Thanks a lot,
Erroneous Seth

[JasonHippy]

Hello to everyone,

I am having this problem with the following code:

typedef struct test
{
	int  i;
	char c[50];
} testStruct;

int main()
{
	char *pData;
	testStruct t;

	t.i = 5;
	strcpy_s(t.c, 50*sizeof(char), "hello");

	pData = (char *)malloc(sizeof(t));
	memcpy(&pData, &t, sizeof(t));
	
	testStruct a;
	memcpy(&a, &pData, sizeof(t));

	cout << a.i << ' ' << a.c << endl;

	system("PAUSE");
	return (0);
}

The problem occurs with the variable "pData", the moment the program returns.

Could someone, please, indicate to me what the problem to the above source code is?

Thanks a lot,
Erroneous Seth

If the problem is occurring when the program exits, it's probably because you aren't freeing the block of memory you're allocating in your call to malloc......It's one of the golden rules of C and C++ that you should free any resources that get allocated, either by using free() (if using the old C style allocations methods, like malloc ) or delete (if using the 'new' keyword to allocate memory).

So at some point before you return, try putting the following line in:

free(pData);

That should hopefully solve the problem!

Cheers for now,
Jas.

[Narue]

>it's probably because you aren't freeing the block
>of memory you're allocating in your call to malloc
No, it's probably not. Even if the process doesn't release allocated memory when it terminates, all you're likely to get is leaked memory, not a segmentation fault.

>memcpy(&pData, &t, sizeof(t));
>memcpy(&a, &pData, sizeof(t));
pData is already a pointer. Remove the address-of operator and watch it magically begin working:

memcpy(pData, &t, sizeof(t));
memcpy(&a, pData, sizeof(t));

[jephthah]

nm

[JasonHippy]

>it's probably because you aren't freeing the block
>of memory you're allocating in your call to malloc
No, it's probably not. Even if the process doesn't release allocated memory when it terminates, all you're likely to get is leaked memory, not a segmentation fault.

>memcpy(&pData, &t, sizeof(t));
>memcpy(&a, &pData, sizeof(t));
pData is already a pointer. Remove the address-of operator and watch it magically begin working:

memcpy(pData, &t, sizeof(t));
memcpy(&a, pData, sizeof(t));

Doh, good point....I stand corrected madam... {hangs head in shame}
I didn't spot the unnecessary usage of &..Although now you mention it, it's glaringly obvious! {kicking self}

He he, ne'er mind....Can't win 'em all...Unless your names Narue that is! heh heh ;)

[Erroneous Seth]

Thank you JasonHippy and Narue for your answers.

Narue, you were right! It worked... Would you mind to elaborate on it? I understand what you said about pData being already a pointer. However, I can't seem to understand why it caused this kind of problem, in the first place.

Thanks a lot!

[jephthah]

I can't seem to understand why it caused this kind of problem, in the first place.

undefined behavior.

some environments would not allow the offending command to even execute. yours allowed it to execute, but not to return from main.

simply put, the prototype for memcpy requires pointers for the source and destination. you supplied a pointer to a pointer.

[Narue]

>I can't seem to understand why it caused this kind of problem
pData holds an address returned by malloc. That address is where your block of enough space to hold a testStruct resides. &pData is a different location in memory altogether. It's a different address where the pData variable itself resides, and there's not nearly enough memory to hold a testStruct there. When you write to the latter address, it corrupts your other stack variables because pData is stored on the stack.

[jephthah]

^ to expand on what Narue just said: the "runtime stack" contains some basic info including the return addresses where the program is supposed to return to .... so you probably overwrote it, wiping out the return address that main was trying to "go" to.... many runtime environments (including one that i use regularly) wouldn't even let that offending line of code be exectued.

...

to help you conceive of the whole thing, think of pointer addreses like mailing addresses. when the postal carrier has a huge box for you, they cant put it in your mailslot. so instead, they put a note in your mailslot telling you they have a huge box for you at some other location that you have to go to in order to retrieve it.

the "mailslot" is the container of the physical pointer, and the "note" is the information that points you where to go. And what you did, was crammed a cubic meter box into a 2 centimeter wide mailslot.

following the analogy to it's conclusion, you can't do that without breaking the structure of the building.

.

[Erroneous Seth]

Thank you guys. It is clear enough to me, now!:)
It is my first time using memcpy and I got a little confused:$

[Erroneous Seth]

Thank you guys. It is clear enough to me, now!:)
It is my first time using memcpy and I got a little confused:$