"0xC0000005: Access Violation" problem with I/O stream

[spetsnaz26]

I've got this annoying "access violation" problem. I've done searching for a whole day on the Internet and although I didn't find any solution specific to my problem I do understand "unhandled exception in abc.exe:0xC0000005: Access Violation" has something to do with inappropriate use of pointers.

However where the error occurs(see the code) there is no reference to any pointer I've defined previously. I also noticed that although when output is called the parameter 'printtype' is set to 2, the program nevertheless executed 'out5.open("designpoints.txt",ios::app);" and the error box popped up.

void output(struct a *pointer, int num, int printtype)
{
int i,j;

ofstream out5;
if(printtype==0)
out5.open("designpoints.txt");
else if(printtype=1)
out5.open("designpoints.txt",ios::app);//where the error occurred
else
out5.open("NDlist.txt");

/****output stuff*************/

out5.close();

}

int main()
{
/*the struct is defined here and abc is the name of an array of this particular struct*/
output(abc,10,2);
}

Whenever the message box popped up with the ubiquitous access violation thing and I clicked the ok button I invariably were asked to provide the file path to "stream.c", or "setlocal.c". It also says there no file by such a name was found in the directory. If I close this window i'd be taken to, invariably, some wierd code window showing the content of "xlocal.h" or sometimes codes such as the following

00439ED9   mov         byte ptr [eax],0
00439EDC   mov         dword ptr [i],1
00439EE3   jmp         _setlocale_get_all+4Eh (00439eee)
00439EE5   mov         ecx,dword ptr [i]
00439EE8   add         ecx,1
00439EEB   mov         dword ptr [i],ecx
00439EEE   mov         edx,dword ptr [i]
00439EF1   imul        edx,edx,0Ch
00439EF4   mov         eax,dword ptr ___lc_category+4 (004a0dc4)[edx]
00439EFA   push        eax
00439EFB   push        offset string "=" (004973b4)
00439F00   mov         ecx,dword ptr [i]
00439F03   imul        ecx,ecx,0Ch
00439F06   mov         edx,dword ptr ___lc_category (004a0dc0)[ecx]
00439F0C   push        edx
00439F0D   push        3
00439F0F   mov         eax,[___lc_category+4 (004a0dc4)]
00439F14   push        eax
00439F15   call        _strcats (0043a140)
00439F1A   add         esp,14h
00439F1D   cmp         dword ptr [i],5
00439F21   jge         _setlocale_get_all+0C9h (00439f69)
00439F23   push        offset string ";" (004973a0)
00439F28   mov         ecx,dword ptr [___lc_category+4 (004a0dc4)]
00439F2E   push        ecx
00439F2F   call        strcat (00440de0)
00439F34   add         esp,8
00439F37   mov         edx,dword ptr [i]
00439F3A   add         edx,1

I want the program to write the content of the struct a to a file, simple as that. output() takes the pointer abc that points to the start address of a certain struct I've clearly defined before calling output(). I've checked that pointer abc pointed to a valid struct I've created and it could not have caused any problem. compile and link did not mention any problem with my code.

I have a hunch that this has to do with my use of ofstream. Any help would be appreciated.

[Salem]

You need to post an actual example code which crashes.

Deleting a bunch of stuff, then saying "something like this code crashes" isn't good enough. You've almost certainly deleted the true cause of the problem and just posted where you think the symptom is.

[spetsnaz26]

I've written the following code that repeats more or less the same problem. struct type abc has three int type variables. structcopy(...) is used to copy the content of a1 to a2. output(...) outputs a2 to an external file.

#include<iostream>
#include<fstream>
struct abc
{int a;
int b;
int c;
};

typedef abc* abcpointer; 

void structcopy(struct abc *pointer1,struct abc *pointer2,int N);
void output(struct abc *pointer, int N);

using namespace std;

int main()
{
abcpointer a1,a2;
a1=new abc[10];
a2=new abc[];//size undefined
int i;
for(i=0;i<10;i++)
{
	a1[i].a=i;
	a1[i].b=i+2;
	a1[i].c=i+3;
}

structcopy(a1,a2,10);//copying a1 to a2

output(a2,10);//prints a2 to a file.
return 0;
}

void structcopy(struct abc *pointer1,struct abc *pointer2, int N)
{int i;
for(i=0;i<N;i++)
pointer2[i]=pointer1[i];
}

void output(struct abc *pointer, int N)
{
	int i;
	ofstream out;
	out.open("test2.txt");//where error occurs

	for(i=0;i<N;i++)
	{out<<pointer->a<<" "<<pointer->b<<" "<<pointer->c<<endl;
	pointer++;}
	
}

What's most annoying about this error is that it’s not consistent. Triggering it at different time seems to lead to different ‘symptoms’.

Symptom 1: stops at output(...) where indicated, message box pops up with the devious access violation message and asks me to specify the path to stream.c, xlocale.h or sometimes led me to a screen full of wierd codes(see the original post)

Then I happened to have restarted the system and noticed the following changes:

Symptom2: after restarting, if the size of a2 is NOT specifed, running the program(Ctrl+F5) leads to "test.exe has stopped working" message box. No output is done.

Symptom3: after restarting, if the size IS specified the program seems to run flawlessly. test1.txt is created and the content of a2 correctly written to this file.

Symptom4: after restarting, if the size of a2 is NOT specified and the program is run step by step( by pressing F10) it stops at where indicated in the code, giving me the good old ‘access violation” message and asked me, instead of the now familiar xlocal.h or stream.c, the file path to setlocal.c.

Symptom5: after restarting, if the size of a2 IS specified and the program is run step by step, everything went smoothly until at the end of the program after passing return 0 I was asked to specify file path to CRT0.c, and there was NO access violation message. Output to test2.txt was performed correctly in this case.

In all of the above cases structcopy(…) performed correctly. At the very least after executing structcopy(..), a2 appears to have the same content with that of a1.

From the above it can be seen that specifying the size of a2 or not before filling it is somehow related to the error occurring or not. But what is wrong with not specifying its size?? Or is there another problem, perhaps with the way I copied a1 to a2?

[mitrmkar]

The fix is simple,

// a1 comes with 10 elements ->
// a2 also comes with 10 elements (at minimum)
a2=new abc[ 10 ];

So, you were simply trashing memory. What was the main idea of doing the a2 allocation like you did? Were you just trying out C++ 'things'?

[spetsnaz26]

The fix is simple,

// a1 comes with 10 elements ->
// a2 also comes with 10 elements (at minimum)
a2=new abc[ 10 ];

So, you were simply trashing memory. What was the main idea of doing the a2 allocation like you did? Were you just trying out C++ 'things'?

I was not trying to trash anything.

I guess it's my mistake not having clarified why I left the size of a2 undefined. The code I wrote in post #2 was meant to repeat the problem I encountered earlier in another programming project. In that program the elements of a2 is made up of a part (a subset) of a1, the amount of which cannot be determined before running another function that 'flags' elements of a1 that need to be transferred to a2. Of course I could use one specialized function to calculate the amount of a1 elements that need to be transferred and then another specialized one to define a2 to accomodate those elements and fill it up, but I thought by leaving the size of a2 undefined AT FIRST I could fill a2 as I discover elements of a1 that should be transferred to a1 and in the end the size of a1 will automatically be what it is needed to accomodate those elements(that need to be transferred).
If the access violation problem indeed lies in a2's undefined size or incorrect struct copying, I meant to ask:

1. What is wrong with leaving the size of a2 undefined, How could this have affected output streams in an apparently unrelated function?
2.And what is the proper way of copying structs?

I hope by this I have clarified my questions.

[mitrmkar]

I was not trying to trash anything.

I didn't mean to say/imply that you were intentionally trying to trash anything just to see what happens, you misunderstood me somewhat there.

>> 1. What is wrong with leaving the size of a2 undefined
You must be in full control of the memory you allocate at all times, i.e. you have to know the size of a given block of memory you've allocated and keep track of it (what do you think was the size of the block allocated for a2??). Otherwise you'll end up writing to memory, which may be reserved/used for something else. In this case it was and produced the nasty side-effects. The pointers don't automatically adjust the size of the memory block pointed to.

>> How could this have affected output streams in an apparently unrelated function?
Again, you simply trashed the memory ( pointer2[i] = pointer1[i] )

>> 2.And what is the proper way of copying structs?
One way is to allocate enough memory and do a memberwise copy. Also you might be interested in checking out overloading the assignment operator (=), which would be more suitable for non-POD types (Plain Old Data).

[spetsnaz26]

Thanks for the help.