Global variable not retaining its assigned value 1

[AlexLaing]

I m writing a program in VC++ .net 2003.

At a particular function it constantly crashes with
"[Program.exe] has encountered a problem and needs to close..."

The line it specifically crashes on is
"string newCaption = gWndCaption + buffer;"

The only thing strange about the line is that [gWndCaption]
loses the value that was assigned to it at the start.

Any reason why this may happen, or why the program may be crashing each time it hits that line?

Thanks in Advance.

 

[ArkM]

What's a type (and allocation) of gWndCaption?
What is it: buffer?
I see newCaption is a (std: string, but others?..

 

[Salem]

There's nowhere near enough information here to even make a guess.

If the code is short-ish, no more than say 100 lines, then post it here. Please use the [tt][ignore]

[/ignore][/tt] tags when posting code.

--

 

[AlexLaing]

Thanks for your replies.

I have included "using namspace std" at the beginning of the module.

"gWndCaption" is the global string that does not retain its assigned value.

"buffer" is a local variable declared as
"static char buffer[256];".

Some more information regarding the problem.

I placed a breakpoint at that line of code,
"string newCaption = gWndCaption + buffer;", and ran the program.

When it stop at the the breakpoint I press F10 and immediately a window appears saying

"Unhandled exception at 0x00417183 in Program.exe: 0xC0000005: Access violation reading location 0x00000118."

A code tab window appears for a module called "memcpy.asm", a sample of the code it contains is

;
; Copy toward higher addresses.
;
;
; The algorithm for forward moves is to align the destination to a dword
; boundary and so we can move dwords with an aligned destination.  This
; occurs in 3 steps.
;
;   - move x = ((4 - Dest & 3) & 3) bytes
;   - move y = ((L-x) >> 2) dwords
;   - move (L - x - y*4) bytes
;

CopyUp:
        test    edi,11b         ;U - destination dword         
                                ;aligned?
        jnz     short CopyLeadUp ;V - if we are not dword 
                                 ;aligned already, align

        shr     ecx,2           ;U - shift down to dword  
                                ;count
        and     edx,11b         ;V - trailing byte count

        cmp     ecx,8           ;U - test if small enough 
                                ;for unwind copy
        jb      short CopyUnwindUp ;V - if so, then jump

        rep     movsd           ;N - move all of our dwords

        jmp     dword ptr TrailUpVec[edx*4] ;N - process 
                                            ;trailing bytes

The highlighted line that is being executed is always at

rep     movsd           ;N - move all of our dwords

This does not make much sense to me, it looks like assembly language, of which I am not familiar with.

Any suggestions as to what may be happening?

I have rebooted the machine and done a rebuild of the application several times, but the exact same problem occurs each time.

 

[cpjust]

Don't worry about the assembly. It's meaningless unless you know assembly and know what you're looking for.

When you get to the "string newCaption = gWndCaption + buffer;" line, put your mouse over gWndCaption and buffer so it shows you what their values are. One of those values are probably messed up. Probably due do uninitialized data or buffer overflow.

If you comment out the "buffer" part and just have:

string newCaption = gWndCaption;

you can see if it's buffer that's messed up.

 

[AlexLaing]

After a thorough investigation I determined what was last changed to the code before the problem occurred.

What I found was that the below declaration, once adjusted, resulted in the program working properly.

"POINT gCell[5][15];"

The above is a POINT structure that is supposed to hold the x/y location for each cell in a grid that has 6 rows and 16 columns.

After I adjusted the declaration to

"POINT gCell[95]; //6 x 16 = 96"

the program worked fine without any application errors.

I do not know if this is a bug with Visual C++, or whether it is illegal to declare a two-dimensional array of POINT structures.

Nonetheless, thanks to everyone for their assistance.

 

[cpjust]

If it's a 6 x 16 grid, shouldn't the declaration be:

POINT gCell[6][16];

If you declare it as an array of 95 POINT's, you'll overflow the array if you ever fill all 96 points of the grid.

 

[AlexLaing]

No, this is not a problem in that the arrays are zero-based.

So ...
5 is {0,1,2,3,4,5}
16 is 0 to 15
96 is 0 to 95

Regards.

 

[cpjust]

Actually, 0-based arrays mean that an array y[x] goes from 0 to x - 1.
Ex. int i[5]; // has indexes from i[0] to i[4].

 

[uolj]

cpjust is correct, when you declare an array, the number in the brackets is the size. So you can index from 0 to size - 1:

int array[5]; // size = 5
cout << array[0]; // Ok
cout << array[1]; // Ok
cout << array[2]; // Ok
cout << array[3]; // Ok
cout << array[4]; // Ok
cout << array[5]; // BAD!

 

[AlexLaing]

Yes you are correct.

That was a typo on my part.

Nonetheless, a 6x16 grid should be correctly declared as:

POINT gCell[5][15];

not

POINT gCell[6][16];

 

[cpjust]

Try running this code and see if you get 96 (i.e. 6 x 16), or 75 (i.e. 5 x 15):

POINT gCell[ 5 ][ 15 ];
cout << sizeof( gCell ) / sizeof( POINT ) << endl;

 

[AlexLaing]

OK! OK!

I have finally seen the light!

Please be patient with me, I am new to C++.
I have been a Visual Basic programmer for years, and the
statement

Option Base 1

would allow the programmer to not have to worry about zero-based arrays, etc.

I see your point. Thanks!

I guess then that the "POINT" declaration was what was causing the problem. I will test it.