Access violation when there is neither a pointer nor an array 1

[csripriya1]

Hi all,
I have a very small code, which reads in data of an object from a file and writes it back to another file.
Here is the code.
#include "class.h"
void main()
{
string ligcrd;
crd lig;
cout<<&quot;Ligand.Crd file :&quot;<<endl;
cin>>ligcrd;
lig.read_crd(ligcrd);
lig.print_crd(&quot;lig_out.crd&quot;
cout<<&quot;Complete&quot;<<endl;
}
When I execute this code,this prints complete then dies out giving access violation with the debug option in Visual C++,I am getting an arrow pointing to this.
0041B4BC mov dword ptr [ecx+4],edi.
I am getting a perfect outfile with all the information.
As I have neither pointer nor an array,I am wondering why this is happening.Can anyone please help me with his.

 

[palbano]

crd lig;

A good guess is that the destructor of that class is causing the problem or of course it could chain into destructors of class members if it is a composite

-pete

 

[adholioshake]

Traditionally, main() function is integer not void returns an integer. It could be that your compiler doesn't like a void main. You could also try using the function exit() to return to OS.

 

[Cagliostro]

I agree with palbano, what are your destructors doing?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[csripriya1]

Hi,
I checked all the arrays that I created using dynamic memory allocation.I am not deleting this before the destructor.I am sure of that.I am wondering why this is happening?.

This is my file where I had declared the class crd.
#include <string>
using namespace std;
#ifndef crdlib
#define crdlib


class crd
{
protected:
float *xcrd,*ycrd,*zcrd,*wei;
int natoms;
int *atnum,*resnum;
string *res,*attype,*side;
int *resid;
float xcrd_min,xcrd_max;
float ycrd_min,ycrd_max;
float zcrd_min,zcrd_max;

public:
crd()
{
xcrd=NULL;
ycrd=NULL;
zcrd=NULL;
atnum=NULL;
resnum=NULL;
res=NULL;
attype=NULL;
side=NULL;
resid=NULL;
wei=NULL;
}
~crd()
{
delete xcrd;
delete ycrd;
delete zcrd;
delete atnum;
delete resnum;
delete res;
delete attype;
delete side;
delete resid;
delete wei;
}
void read_crd(string);
void print_crd(char*);
};
#endif


your advice and suggestion on this would be highly appreciated.Thanks a lot.

 

[JOLESEN]

In your destructor you delete a lot of pointer variables, without testing if they were ever used for anything (i.e. assigned the address of some allocated memory).

Somewhere in your class :
xcrd = new float[32];

Now check before deleting :

if(xcrd) delete [] xcrd;
etc.

/JOlesen

 

[tokra]

I thought that language was clear about beeing able to delete a NULL pointer safely. You aren't using the array form of delete though. That is definitly causing memory leaks, but it might be the cause of your problems.

WR

 

[PerFnurt]

You are correct, you can safely do a delete NULL.

There is no reason to do a conditional delete like

if(foo) delete foo;

just delete away.

It follows the paradigm that deallocation (and destruction in general) should NEVER fail.

What's the code for read_crd, and print_crd?

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[Cagliostro]

look in: void print_crd(char* _x);
doeas any member of classes initialize to _x? If so, youre trying do in destructor to delete a member of string ligcrd. ligcrd will try to delete it again.
I assume you have some other name for _x. Could you please post theer the body of this function?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[csripriya1]

Hi all,
Thanks for your suggestions.This is the code for print_crd.
#include <fstream>
#include <stdlib.h>
#include <iomanip>
#include <string>
#include <iostream>
using namespace std;


#include &quot;crd.h&quot;

void crd:rint_crd(char *stra)
{
int in;

ofstream outfile(stra,ios:ut);
if(!outfile)
{
cerr<<&quot;File could not be opened&quot;<<endl;
exit(1);
}

cout.setf(ios::showpoint);

outfile<<&quot;*\n&quot;;
outfile<<setw(5)<<natoms<<endl;

outfile.setf(ios::fixed,ios::floatfield);
outfile.setf(ios::showpoint,ios::right);
outfile<<setprecision(5);
for(in=1;in<=natoms;in++)
{
outfile.unsetf(ios::right);
outfile.setf(ios::right,ios::adjustfield);
outfile<<setw(5)<<in
<<setw(5)<<resnum[in]
<<setw(1)<<&quot; &quot;
<<setw(3)<<res[in]
<<setw(2)<<&quot; &quot;;

outfile.unsetf(ios::right);
outfile.setf(ios::left,ios::adjustfield);

outfile<<setw(4)<<attype[in];

outfile.unsetf(ios::left);
outfile.setf(ios::right,ios::adjustfield);

outfile<<setw(10)<<xcrd[in]
<<setw(10)<<ycrd[in]
<<setw(10)<<zcrd[in]
<<setw(1)<<&quot; &quot;;

outfile.unsetf(ios::right);
outfile.setf(ios::left,ios::adjustfield);

outfile<<setw(4)<<side[in]
<<setw(1)<<&quot; &quot;
<<setw(4)<<resid[in];

outfile.unsetf(ios::left);
outfile.setf(ios::right,ios::adjustfield);
outfile<<setw(10)<<wei[in]<<endl;
}

}
In this code I am not deleting any of the arrays for which I had allocated memory dynamically.
Thanks for your time

 

[Cagliostro]

in this case you should use debugger and get what is exactly the row where the error is.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[JOLESEN]

PerFnurt : Didn't know that delete null-ptr was possible / safe. Star for you.

/JOlesen

 

[PerFnurt]

Thanks.

Note that this also implies it is always safe to do a delete on whatever value returned by new (and new might return NULL).


/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[PerFnurt]

Note2:
This also implies why one should always assign the pointer to NULL after deletion (delete doesnt do it for you), it is a way make the pointer &quot;harmless&quot; for further deletions (and of course a pointer beeing NULL is clearly not pointing to anything, which is a good thing to clarify in the code).


/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[Cagliostro]

csripriya1,
I have created a project what is identically with the program you described there. I had no exception. Could you contact me directly?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com