C / C++ / MFC

6-Jul-03 21:17

I decided to try out some of the new features in VS studio NET 2003.
One of these is the /RTCs switch, which does overrun and underrun checking of all multi-byte local variables such as arrays.
However I found that it only works half the time, for instance this code fails to give me any error:
int test[2];
test[3] = 1;

but this code will cause the run type check:
char test[2];
test[3] = 1;

Anyone use this feature? Anyone know why it doesn't work properly?
thanks in advance,
Ed

Mike Dimmick7-Jul-03 4:00

Mike Dimmick

7-Jul-03 4:00

Ah ****, I didn't bring my Debugging Applications for Microsoft.NET and Microsoft Windows[^] in to work today.

Robbins definitely covers this subject in this book. Recommended read for all C++ and .NET developers (which is basically everyone!)

I think the answer is just coincidence: you may have overwritten that location with a value that it still considers valid, or it might be something to do with padding (?)

--
Mike Dimmick

ed welch7-Jul-03 4:29

7-Jul-03 4:29

Yes, I think this feature works by putting special bytes at the beginning and end of each array and then checking at the end of the program if these bytes were overwritten.
But for whatever reason it only seems to work about one in ten times. I tried changing the padding and it doesn't make any difference.
It's a pity because it would be a nice feature.

Mike Dimmick7-Jul-03 22:50

Mike Dimmick

7-Jul-03 22:50

I cheated; I looked at the compiled code (use the /FAcs option, or set Configuration Properties > C/C++ > Output Files > Assembler Output to Assembly, Machine Code and Source in the project Properties box).

The compiler allocates 200 bytes more on the stack than the routine actually needs when /RTC1 (the combination of /RTCs and /RTCu) is enabled, rounded up to the nearest multiple of 4. The allocated region is then filled with 0xcc (the reason for the multiple of 4 is so that the compiler can use a simple fill-memory instruction).

However, for some reason, the compiled code starts using locals at the normal point, e.g. in your first example, test[0] is at ebp-12 (the frame pointer is stored in the ebp register, and the stack grows down in memory). The allocated space is great for underruns, poor for overruns.

As such, when the compiler compiles test[3] = 1, it generates code to modify the value of [ebp]. This location is where the called function stores the value of the previous function's frame pointer: an area which isn't checked by the /RTCs option. This explains why my test compilation blows up in main(), with the following error:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

It's not an exact science, this.

I do think the compiler's doing something odd: it's difficult to trap buffer overruns if the buffers are being allocated this close to the danger area (of previous frame pointer and return address). The other odd thing it's doing is generating clearly incorrect code!

Oddly, the default compiler options for a Debug build don't include the /GS (Buffer Security Check) switch. This stores an XOR of the return address with a generated 'security cookie' elsewhere in the function's stack frame; at the end of the function, the return address and cookie are compared, and a runtime error occurs if they don't match. However, the documentation states that this occurs "on functions that the compiler thinks might be subject to buffer overrun problems" - in other words, according to an undocumented heuristic.

Robbins recommends enabling /GS even in your Debug build.

--
Mike Dimmick

ed welch8-Jul-03 21:27

Deciphering memory leak dump

8-Jul-03 21:27

Thanks for the info. Looking at it more closely now, I think that the buffer checking only checks the word immediately after the end of the array. If I set test[2] = 0; it does trigger the buffer overrrun warning.

paulb6-Jul-03 20:39

paulb

6-Jul-03 20:39

I'm getting this object dump from a memory leak....

Detected memory leaks!
Dumping objects ->
{75} normal block at 0x00335668, 8 bytes long.
Data: < > 01 00 00 00 02 00 00 00
{74} normal block at 0x00335600, 40 bytes long.
Data: < B hV3 > A0 EE 42 00 C4 FD 12 00 68 56 33 00 02 00 00 00
{73} normal block at 0x003355B0, 16 bytes long.
Data: < B 8 V3 > 14 EF 42 00 02 00 00 00 38 FE 12 00 00 56 33 00
{70} normal block at 0x003353A0, 380 bytes long.
Data: <dg g="" u3=""> 44 67 04 10 1C 67 04 10 B0 55 33 00 01 00 00 00
Object dump complete.

Is there any information in here that will help me track down the problem? it all looks like gobbledygook to me.

Re: Deciphering memory leak dump

peterchen6-Jul-03 21:47

peterchen

6-Jul-03 21:47

a) compile with (more) debug info, if possible
b) start at bottom, the later allocations might be dependent on the bottom one.
c) does the size of the structure ring a bell?
b) the first number is the "allocation number" (i.e. the 70th allocation leaks memory)
Typically they are "stable". If so, you can use _CrtSetAllocHook, which gets called for each allocation, set a cond breakpoint for allocation number == 70, and look at the stack trace from there.

"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS

sighist | Agile Programming | doxygen

KaЯl7-Jul-03 3:40

KaЯl

7-Jul-03 3:40

peterchen wrote:
If so, you can use _CrtSetAllocHook, which gets called for each allocation, set a cond breakpoint for allocation number == 70, and look at the stack trace from there.

You can do it one step using _CrtSetBreakAlloc(70) at the beginning of the program.

We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)

Re: Deciphering memory leak dump

Xander807-Jul-03 1:15

Xander80

7-Jul-03 1:15

I use:

#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>

at the top of my application, and:

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

at the start of my application (first function).

More information about the object that caused the memory leak will appear in the debug information.

Re: Deciphering memory leak dump

ed welch7-Jul-03 4:10

Why doesn’t show bitmap, when button is disable?

7-Jul-03 4:10

Yes, I notice that the VC6 dump tells you which object caused the leak and VC7 doesn't Frown | :(

_CrtSetDbgFlag doesn't make any difference.

no_body696-Jul-03 19:57

no_body69

6-Jul-03 19:57

Hi,
I set bitmap in default button. When button enable, button is display with bitmap. But when button disable then bitmap doesn’t show in button and button is shown with another color.
Here is my code:

HBITMAP hbmp =::LoadBitmap(AfxGetInstanceHandle), MAKEINTRESOURCE(IDB_BITMAP_OK));

::SendMessage(GetDlgItem(IDC_OK)->GetSafeHwnd(), BM_SETIMAGE, (WPARAM)IMAGE_BITMAP,(LPARAM) hbmp);

hbmp = NULL;

I also checked Bitmap option from button properties.

My problem is that, I want to show button with bitmap when it is disable (same as when button is enable).

Anybody can tall me, how can I solve this problem?

Re: Why doesn’t show bitmap, when button is disable?

Rage6-Jul-03 21:49

Rage

6-Jul-03 21:49

Make sure the style of your button does not require more than one picture (the common "three states" requires a picture for normal state, a picture for "pushed" state and a picture for disabled state).
If not, then invert the problem, make a button with three states, and provide the same picture for the normal and grayed state.

~RaGE();

Re: Why doesn’t show bitmap, when button is disable?

no_body696-Jul-03 23:12

no_body69

6-Jul-03 23:12

HBITMAP hbmp =::LoadBitmap(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_BITMAP_OK));
GetDlgItem(IDC_OK)->GetSafeHwnd()->SetBitmap(hbmp);

This code give me a error. that is : 'SetBitmap' : is not a member of 'HWND__'

Re: Why doesn’t show bitmap, when button is disable?

no_body697-Jul-03 0:47

no_body69

7-Jul-03 0:47

Hi,
Thank you for reply.
yes, this code is ok. but it didn't solved my problem.
when button is disable, it doesn't show bitmap.
i want to show bitmap in button when button is disable.

screensaver problem

xxhimanshu6-Jul-03 18:41

xxhimanshu

6-Jul-03 18:41

Hi all,
I have a small problem..I have an MFC application..and I want to enable screensaver or disable screensaver on meeting some condition...can I do it..I tried searching for it in google, codeproject etc..but hard luck...nothing is there..can anyone out there help me out...any help or pointers are highly appreciated..
Thanks a lot in advance..

Himanshu

Ryan Binns6-Jul-03 18:58

Ryan Binns

6-Jul-03 18:58

Do you want to disable it permanently or just while your program is running?

To disable it permanently, you might have to write to the registry or use SystemParametersInfo(), although unless your program is specifically to change the screensaver, then most users won't like you doing this.

To disable it temporarily, look at SetThreadExecutionState(ES_DISPLAYREQUIRED). This function is supported on Win98 or later.

Hope this helps,

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

xxhimanshu6-Jul-03 19:49

xxhimanshu

6-Jul-03 19:49

Hi,
Thanks..i tried using systemparametersinfo() but seems as if it is not enabling the screensaver..i want to enable screensaver like on event when I press OK button..but it is not happening...and disabling i dont require..sorry..I think it will automatically disable if we press any key or move mouse..Please help...
Thanks in advance..

Himanshu

Ryan Binns6-Jul-03 20:13

Ryan Binns

6-Jul-03 20:13

Oh, you want to start the screensaver running whenever you like? A screensaver is just an exe file on your hard-drive. The name of the screensaver file the user has selected is in the registry, at "HKEY_CURRENT_USER\Control Panel\Desktop\SCRNSAVE.EXE". Read this value and pass it to ShellExecute() and that will run the user's screensaver.

Hope this helps,

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"