dim shared variables losing values

[elsairon]

I have a strange effect occurring in my project currently which I am so far unable to reproduce in an example.

I have set some variable values using dim shared.

Some of these values are lost when setting screen mode using the Screen command, depending on which mode I use.

In modes 13, 16, and 17 these values are safe.

Using Screen Modes 14, 15, 18, and 19 cause these dimmed variables to become value zero.

In addition, when using the width statement in Screen Modes 16 and 17 such as;

Code: Select all

Screen 16
Width 68,48

'and

Screen 17
Width 80, 50

also cause these dim shared variables to be reset to 0.

Simple examples I have tried to re-create this problem so far have not worked. Has anyone came across this problem before?

[MichaelW]

I cannot duplicate the problem.

Code: Select all

dim shared as integer a = 1, b = 2
screen 13
print a, b
sleep 3000
screen 19
print a, b
sleep 3000
screen 16
width 68,48
print a, b
sleep

[elsairon]

After some more testing I have found that changing the order in which the variables are dimensioned changes which variables lose their value.

The first two retain their value while the rest are lost.

for example

Code: Select all

dim shared as integer a,b,c,d,e,f

causes values a and b to retain their values, while c,d,e and f are set to zero.

changing the order of dim shared as

Code: Select all

dim shared as c,d,e,f,a,b

causes values of c & d to be retained while the rest have lost value after the screen statements.

[integer]

I have a strange effect occurring in my project currently which I am so far unable to reproduce in an example.
...
Simple examples I have tried to re-create this problem so far have not worked. Has anyone came across this problem before?

If you cannot reproduce the effect in a short fragment, how can you be certain that it is the screen command? Just wondering here.

You should be able to determine the values just before you invoke Screen and then display the values immediately after. If these are shared values make absolutely certain that some function/subroutine is not actively altering the values.

I have tried all of the screen/width combinations available to my system: the values hold.

How big is your program?

[Zippy]

"A shot in the dark."

Try increasing your stack size when you compile. I think the default is:

fbc -t 1024 ..

Try:

fbc -t 2048 ..

You may have enough other variables on the stack that with these additional descriptors you run out of stack. I'm guessing.

[KristopherWindsor]

Compile with -exx to check for out of bounds array access.

[vdecampo]

Make sure you are not using one or more of these variable names as a counter...ie

Code: Select all

Dim Shared As Integer a 

a= 10
Print a

For a  = 0 To 5
   Print a
Next

Print a

sleep

If you change the FOR to declare the variable as a temp then this doesn't cause a problem.


-Vince

[Richard]

The declared variables are pushed on the stack as they are declared, but the stack grows downwards, so the last declared is lowest in memory. If you are writing just above the upper bound of an array stored below the variables then that could explain it.
If you write using pointer arithmetic then errors with that could cause the declaration order sensitive symptom. Pointer arithmetic is not checked by compiler option –exx.

[vdecampo]

I thought shared variables were not declared on the stack but on the heap....

-Vince

[elsairon]

Thanks for the ideas. I should have time to test them out tomorrow and I'll get back with the results.

When I include -exx array bounds checking, the program crashes with no error messages.

Using -t 1024 and -t 2048 doesn't produce any changes.

I do not use these specific variable names in any loops.

The problem is that some shared variables are becoming zero, when there are no instructions setting them to zero.

I wondered if this was a scope error, but I don't think so because I'm using shared variables to avoid that issue.

[MichaelW]

If the value of a variable is changing, then there must be an instruction somewhere that is changing it. This is not very well worked out, but assuming that you are running Windows 2000 or later it might provide a reasonable method of finding the problem instructions.

Try.bas is available here:

http://www.freebasic.net/forum/viewtopi ... 7107#37107

And here is an example:

Code: Select all

'========================================================================
#include "windows.bi"
#include "try.bas"
'========================================================================

'---------------------------------------------------------------
'' Isolate the target variables between page-size pads. Because
'' VirtualProtect acts on full pages, this will ensure that the
'' affected pages will not include any other variables that the
'' program might access. This assumes, without checking, that
'' the system page size is 4096 bytes.
'---------------------------------------------------------------

dim shared as integer pad0(1023)
dim shared as integer a,b,c,d
dim shared as integer pad1(1023)

dim as integer flOldProtect

'--------------------------------------------------------------
'' Change the protection for the pages that contain the target
'' variables so any access to the variables will trigger an
'' exception, and the final exception hander will report the
'' address of the accessing instruction. Note that access here
'' includes read access.
'--------------------------------------------------------------

VirtualProtect( @a, 16, PAGE_READWRITE or PAGE_GUARD, @flOldProtect )

'------------------------------------------------------
'' Install the final exception handler. The choice of
'' EXCEPTION_CONTINUE_EXECUTION will allow the program
'' to continue executing after the exception handler
'' returns, but only because for a guard page exception
'' the system automatically removes the memory page's
'' guard page status.
'------------------------------------------------------

try_begin( EXCEPTION_CONTINUE_EXECUTION )

'-------------------------------------
'' This prevents the message box from
'' ending up behind the console.
'-------------------------------------

sleep 1000

'--------------------------------------------------------
'' Display the address of the next executable statement.
'--------------------------------------------------------

address

'--------------------------------------------
'' Place a comment in the asm output file to
'' mark the problem instruction.
'--------------------------------------------

comment( problem here )

'-------------------------
'' Trigger the exception.
'-------------------------

a = 1

'-------------------------------
'' Reset the guard page status.
'-------------------------------

VirtualProtect( @a, 16, PAGE_READWRITE or PAGE_GUARD, @flOldProtect )

'--------------------------------------------------------
'' Display the address of the next executable statement.
'--------------------------------------------------------

address

'--------------------------------------------
'' Place a comment in the asm output file to
'' mark the problem instruction.
'--------------------------------------------

comment( problem here )

'-------------------------
'' Trigger the exception.
'-------------------------

b = 1

sleep

[elsairon]

I will try out your exception handler macro on the problem code. I'll post my further questions/results in this thread when I do so.

Thank you MichaelW.

[wolfstar]

are you using a variable for the screen parameter or a number?