Out of Memory Errors - The Follow up

[Kalisto]

Ok, thanks to anyone who tried to help me so far.
after sitting down with a manual, and a bit of luck I have managed to move onward.

I now have an exception, but if it is ignored, the application runs and gives me all the information I need.

I have identified the code section that is causing the problem below.

It seems that after I have output a short data type, the next data that is output will cause this exception.

short temp = sHeader.iCipherValue; 
*pLF << temp;
*pLF << L&quot;\n&quot;;
			
//Parse through the Directory 
// as *.* is used, this code will also get directories.
wchar_t* szFindPath = new wchar_t;
wcscpy(szFindPath,szFolderPath);
wcscat(szFindPath,L&quot;\\*.*&quot;);
	
//Convert Char_W Array into an LPSTR for find access
lpFind = CW2A(szFindPath);

strOut = L&quot;First Entry = &quot;;
*pLF << strOut;	<-- This causes the error message			

//Find the First Entry in this Folder, be it a Directory or a File
HANDLE hFind = FindFirstFile(lpFind,&lpData);

I know that it's not my operator<<, as they work for everything else without issue.

Any ideas ?

K

 

[palbano]

Did you step into your operator <<() function? What do you see in there for value of the object and the input parameter?

Post the code for the operator function and the runtime values as seen while debugging.


-pete

 

[JOLESEN]

You don't allocate sufficient memory for your string.

Change
wchar_t* szFindPath = new wchar_t;

to something like
wchar_t* szFindPath = new wchar_t[512];

/JOlesen

 

[palbano]

Oh my... was that ever funny

-pete

 

[Cagliostro]

sorry but is your file write protected (ReadOnly or something like no privileges)?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Cagliostro]

In addition, is it a file or a directory?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Kalisto]

It is a file, and it isn't protected, as the write commands before it work (and once I ignore the exception, those after it work as well.)

Pete, I'll run thru the << in a bit, but the value of hte string goes into it, and the stream is opened for output normally. This all works, including that particular function for everything else, it is just that one command.

Tracking backwards though (into code I didn't display, the previous << is of type short, and if that is removed, then there is no error, so it is looking like that is the cause of the problem, and the strOut << is merely what is showing the symptoms.

I'll post it up later when I get back into the office.

K

 

[Kalisto]

OK, heres teh Operator<< function for wstring

// Operator Override of the << function using string
CLogger& CLogger::operator<<(const std::wstring T)
{
	std::wofstream* fs = new std::wofstream;
	if (!fs->is_open())
		OpenLogFile(fs);
	try
	{
		*fs << T;
		fs->flush();
	}
	catch(std::ios::failure)
	{
		printf (&quot;Exception Thrown.\nCannot Find File %s\n&quot;,strFname.c_str());
	}
	fs->close();
	return *_CLogger;
}

and heres the fileopen code

// Public Function to allow Operators to work
void CLogger::OpenLogFile(std::wofstream* fs)
{
	try	
	{	
		fs->open(strFname.c_str(),std::ios::out|std::ios::app);
	}
	catch(std::ios::failure)
	{
		printf ("Exception Thrown.\nCannot Find File %s\n",strFname.c_str());
	}	
}

 

[Cagliostro]

what is your strFname,
You're sure it is initialized corectly?

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Kalisto]

strFname is a member variable of the CLogger class. I am assuming it is initialised correctly as there are writes before this code that work successfully, and if I disable that code section, then writes after the event also seem to work.

The only thing that has just struck me is that I have made my Logger class a singleton. If I am chaining my operator<< funcitons together by returning a reference to CLogger, am I going to get issues with my copy constructor ?

K

 

[palbano]

Kalisto, did you fix the error the JOleson pointed out. Until you fix that all bets are off since you are corrupting memory. These types of errors cause undefined behavior that can change every time you alter the memory layout of your app.

-pete

 

[Cagliostro]

look at theese lines:
wchar_t* szFindPath = new wchar_t;//????
wcscpy(szFindPath, szFolderPath);
wcscat(szFindPath, L&quot;\\*.*&quot;


Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Kalisto]

*Smacks head repeatedly with keyboard. Nope I didn't, and now I did it throws up a load of new problems. Before I come back here with them I am going to spend a day or 2 looking at them first, in case the answer is a simple again.

Sometimes I wonder why I agreed to take on C++ and leave the nice safe world of Process Automation behind.

Thanks all, it's been a lesson I suppose !

K