Run-Time Check Failure #2 - Stack around the variable was corrupted

[weberm]

I'm something of a C++ novice and I have this legacy code C++ program I am attampting to update. Basically, this program scrapes the contents of an emulator, formats, and then sends the data to a specialized printer. This code compiled in VS 6.0 without any problems but now when I compile it in VS .NET it throws a stack error message for variable psL when it is executed.

// -------------------------------
// Print Bundle Summary
// -------------------------------
void	PrintBundleSummary()
{
	int	i;
	const	int	MAXLINES = 18;
	const	int	MAXLENGTH = 67;
	union psLineU {
		char	psLine[MAXLINES][80];
		char	psLinew[1440];
	} psL;
	char sWork[128];

	PrinterStart();
	RCPprinterControl(RCPCLOSEJAW);

	wFldLen = sizeof psL.psLinew;
	wFldLoc = 91;
	RCPCopyPSstr(psL.psLinew, wFldLen, wFldLoc);               //Scrape contents of emulator screen

	for (i=0; i<MAXLINES; i++) {
		psL.psLine[i][MAXLENGTH] = '\0';
                sprintf (sWork, "%s\r\n", psL.psLine[i]);      //Build sWork
                PrinterSendDataString (sWork);                 //Print contents of sWork
	}

	RCPprinterControl(RCPSTARLINE);
    
	RCPprinterControl(RCPPAPEREJECT);
	RCPprinterControl(RCPPAPEREJECT);

	PrinterStop ();
	return;
}

Obviously, this is happening in the FOR loop yet my printer prints fine and it never complained about it in VS 6.0. I reduced the value of MAXLINES but that didn't fix anything and it didn't print the last line, so 1) why does .NET think it's wrong and 2) how do I fix it?

Thanks!

 

[fheyn]

build sWork using a loop and look what happens

and you know that inserting '\0' will overwrite data.

 

[weberm]

build sWork using a loop and look what happens

You mean using something other than a FOR loop?

you know that inserting '\0' will overwrite data.

I understand that '\0' is used to indicate the end of a line so the rest of the array is ignored, but that's about the extent of my knowledge. Is the way it is handled in .NET different than VS 6?

 

[cpjust]

What do RCPCopyPSstr() & PrinterSendDataString() do to the variables you pass in to them? My guess is that one of them is overflowing a buffer.

 

[fheyn]

try this :

sWork[MAXLENGTH] = '\r';
sWork[MAXLENGTH+1] = '\n';

for (i=0; i<MAXLINES; i++) {
for (j=0; j < MAXLENGTH; j++)
sWork[j] = psL.psLine[j];

PrinterSendDataString (sWork);
}

 

[xwb]

What is wFldLoc? Should it be less than MAXLINES or MAXLINES+ 1 (19)?

 

[weberm]

What is wFldLoc? Should it be less than MAXLINES or MAXLINES+ 1 (19)?

wFldLoc is the starting position on psLinew. I guess I need to take a step back before I continue. This program scrapes the contents of the emulator, 18 rows of 80 characters, and stores them in psLineU, a single array of (18*80) 1440 characters. RCPCopyPSstr copies wFldLen characters, begining at wFldLoc to psLinew. Because the printer is narrow, I am only sending the first MAXLENGTH characters to it in the FOR loop.


On a related note, I think I found the problem, or at least am heading on the right track. I think the problem involves this union

union psLineU {
        char    psLine[MAXLINES][80];
        char    psLinew[1440];
    } psL;

and this code snippet

    wFldLen = sizeof psL.psLinew;
    wFldLoc = 91;
    RCPCopyPSstr(psL.psLinew, wFldLen, wFldLoc);              //Scrape contents of emulator screen

It would appear that psLinew is not the same size as psLine. After some experimententation, I determined that psLinew is too small, but I am not sure what the correct size should be. I enlarged it and assigned wFldLen the constant value 1440 and it runs fine now. Does anyone have an idea why the sizes were no longer correct?

 

[cpjust]

Unless my calculator is wrong, they should be the same size.
18 x 80 = 1440

 

[xwb]

Why not set it to (80*MAXLINES). Then it will adjust accordingly.

 

[fheyn]

if you store at position x, your array can only handle
1440-x bytes.

 

[weberm]

I found it. For some reason, VS C .NET insists that psLinew be 1441. I am guessing the extra char is for the string terminator, but it's odd that it didn't care when I compliled this under VC++ 6...

 

[cpjust]

How big is the actual data that you store in there?
If it's a string with 1440 chars or more, then obviously you'd need to make the variable big enough for the string + the '\0' on the end.

In debug mode, VC++ adds 2 extra chars before & after every buffer, which I believe should be set to this hex value 0xFDFD. That way, you can easily find buffer overflows in your debugger by checking if those bytes got changed to some other value.

 

[xwb]

It probably did matter but the run time probably didn't go over the stack frme or corrupt the word boundary so it looked as if it wasn't a problem.