Announcement

**Lance Edmonds** · 28 Nov 2000, 02:26 PM

Email the code and all necessary data files to Tech Support and we'll look into your problem and see if we can spot the problem.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Michael Mattias** · 28 Nov 2000, 04:59 PM

I ran into that problem a couple of times myself.

Fixed it by using a couple of $SEGMENT metatstatements.

Seems PB will compile but might get squirelly when it gets near a segment boundary.

Just checking.. you DID validate that your subscript was in range after you got the error #9, didn't you?

MCM

Editing 11/28: I just noticed, you have $ERROR BOUNDS OFF in your PBC compile. That will disable the error 9!!

Recompile with $ERROR ALL ON and you'll probably get the error.

Then use the Compile/FindError to locate the source code line where the error occurs.

------------------
Michael Mattias
Racine WI USA
[email protected]

[This message has been edited by Michael Mattias (edited November 29, 2000).]

**Davide Vecchi** · 29 Nov 2000, 03:02 AM

About validating that my subscript was in range when the error occurrs, here is how i ...decided that it was. I hope i didn' t made a mistake.

- The array was dimensioned with

DIM DYNAMIC FmtCMX_s(1 TO 2, 1 TO 7) AS STRING, IntestCMX_s(1 TO 2, 1 TO 7) AS STRING

and the error is on a reference to element (1, 7) of IntestCMX_s:

IntestCMX_s$(1, 7) = zTAB$+"TSU"

Two statements before the error, there is a reference to element (1, 6), which gives no error: IntestCMX_s$(1, 6) = zTAB$+"MMM".
The array is dimensioned only once, with the above DIM, so actually i can' t see any reason for (1,6) to work and (1,7) not to.
It seems me that the error is not related to array dimensioning. However, i don' t feel very comfortable with the statement i used to share the array with one unit:

PUBLIC FmtCMX_s$(MIN, 2), IntestCMX_s$(MIN, 2)

But according to the manuals it seems me to be correct.

- The error is reported to be on a line which is in the main module header (initialization), far before the beginning of the 1st user loop. But when the error occurrs, the program execution is definitely inside that loop (and many others).

- If i compile the main module with PBC instead of the IDE, that error disappears.
So, if my subscript was out of range, the runtime error would be right and due, but we would be now talking about the why a due runtime error is triggered by PB and not by PBC.

- If i REM the previously mentioned FUNCTION in the unit, PB and PBC both compiles to an exe which runs fine.

Michael,
<<
"I ran into that problem a couple of times myself. Fixed it by using a couple of $SEGMENT metatstatements."
>>
Do you "just" fixed some of these UFO errors, or using $SEGMENT helped with differences between PB and PBC?

**Davide Vecchi** · 29 Nov 2000, 03:22 AM

Michael, i just read your re-edited note, but i' m not understanding.

<<
"I just noticed, you have $ERROR BOUNDS OFF in your PBC compile."
>>
I' m not sure if you mean the screenshot i had included in my post:

Error tests
+--------------------+------------
¦ Stack test Off ¦
¦ Bounds test Off ¦
¦ Overflow test Off ¦
¦ Numeric test Off ¦

Anyway, i have $ERROR ALL ON in each unit and in the main module. This should override the settings made from the IDE and from command line options. I really hope not to be wrong on this...

<<
"Recompile with $ERROR ALL ON and you'll probably get the error."
>>
No, i' m actually compiling everything with $ERROR ALL ON, and if i do it with PBC, no errors.

**Mike Luther** · 29 Nov 2000, 11:09 AM

And Mike ...

Seems PB will compile but might get squirelly when it gets near a segment boundary.

Those who run into this also need to know that when you run into
this, and you do break MAIN up into pieces, you'll often run into
all kinds of wierd things that can be fixed even after you use the
$SEGMENT technique! I find there is something specifically around
the 45K segment size boundary that evokes this, but I cannot isolate
it at all. If you add or take away a line or so of code either side
of the boundary - the error(s) simply vanish.

You'll 'fix' the problem with $SEGMENT. You'll go for a long time
and never see anything. Then all of a sudden the code will come
apart again! All it will take is to move the $SEGMENT statement
a few lines either way and the corruption simply vanishes.

I've tried pointering things, everything I can think of in these
large programs to isolate it. I cannot. And I have furnished code
that demonstrates it which hasn't apparently been of use finding it,
either.

I don't pose to be any expert at all at any of this. As best I can
purely guess, in that variable corruption in and around CALL's is
seemingly related as well, I wonder if it is all related to byte
mis-alignment on segment boundaries?

The simplest thing to do seems to be just use $SEGMENT, together
with MEMPACK, even though MAIN isn't at 64K, but at 45K, and just
go about life and forget the whole thing. Just be prepared to
shift the location of $SEGMENT up or down and go on about life.
Odd this should be posted right now. I've got a MAIN in development
right now at 82K split into 45K and 37K, based on a quite reasonable
best guess at what will eventually be yet another PBU. I've moved
the $SEGMENT boundary two times now in four days just to cure
this same sort of stuff. It's trivial now that I know what to do
when it happens, but until I figured out the ring-around-the-rosy,
it was frustrating.

------------------
Mike Luther
[email protected]

**Lance Edmonds** · 29 Nov 2000, 01:28 PM

At this time, Tech Support has received Davide's code but not yet had time to analyse it.

However, since several people are keen on posting anecodal evidence without sending or posting compilable code to prove their claims, we must fairly and reasonably point out that these types of problems are most often due to memory corruption and the causes can be wide an varied, and are usually not in the section of code that shows up a problem.

Common examples are O/S memory manager issues (bugs!), the misuse of pointers, bad inline assembly, etc. These types of problems are not often caught by $ERROR ALL ON since they are not usually "errors" per se, but it certainly helps to add that meta-statement to help catch "simple" bounds errors, null-pointers, etc.

Of course, if you use ON ERROR RESUME NEXT in your code and fail to test for error conditions, you'll do yourself an injustice too, as you'll simply "miss" the error condition when it occurs.

So, at this point in time, if anyone has code that points to a possible or suspected bug in the compiler - then PLEASE submit it to Tech Support... unless we can duplicate/confirm a problem of this nature, we can't fix it.

On this basis, posting unproven/anecdotal stories helps no one and can cause unnecessary time loss chasing red-herrings. What concerns me is that PowerBASIC have pointed these facts out to certain BBS members before, and yet example code to back up these (as yet) unproven claims remains sight-unseen.

In fairness, I should mention that we have received code that concerns minor issues (unrelated to this thread) and for that we are grateful.

We thank you for your cooperation on this matter, and we will post the results of out analysis of Davide's code when the analysis is complete.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Michael Mattias** · 30 Nov 2000, 02:34 AM

Just for the heck of it, what happens if you go to zero-based arrays?

Code:

DIM thearrays(0 to whatever, 0 to whatever) AS whatever
PUBLIC thearrays(MAX,2)

Sure, you waste 2 bytes per array per dimension (the "0" elements), but you get more efficiency and maybe in this case, working code.

MCM

**Davide Vecchi** · 30 Nov 2000, 04:24 AM

<<
Just for the heck of it, what happens if you go to zero-based arrays?
DIM thearrays(0 to whatever, 0 to whatever) AS whatever
PUBLIC thearrays(MAX,2)
>>

Further to your suggestion i tried:

DIM DYNAMIC FmtCMX_s(1 TO 2, 1 TO 7) AS STRING, IntestCMX_s(0 TO 2, 0 TO 7) AS STRING
PUBLIC FmtCMX_s$(MIN, 2), IntestCMX_s$(MAX, 2)

The error 9 turned into Error 208 at pgm-ctr: 6992 (invalid string handle).
It is the next line: FmtCMX_s$(1, 7) = zTAB$+"\ \"
The docs says that this is similar to error 242: String space corrupt.
The same if i keep using MIN but use "0 TO" instead of "1 TO".

I' m sure i went near some boundaries of something somewhere more and more during development, without being aware of it due to my insufficient knowledge of these aspects.
Now i got too near, i went over.
The only thing i know i have to do about these problems, is keeping each compiled code segment under 60K, but i' m sure that with more experience and knowledge about these things, i would have followed development guidelines that would have not even made me fall into this. BTW, the only loss is that i can' t debug with PBD anymore, which is very useful. I ever can get running EXEs.

**Michael Mattias** · 30 Nov 2000, 06:55 AM

242 String space corrupt? That could be an offshoot of an error 9 (array bound violation).

Or, you could have a SUB/FUNCTION in an external module with a DECLARE whcih does not match the procedure and the stack is corrupt;or, you could have insufiicient stack (this is not likely).

The first situation I describe is this

Code:

' UNIT.BAS
 FUNCTION MyFunc (A AS INTEGER, B AS INTEGER) AS INTEGER PUBLIC
 ' cool code  
 END FUNCTION

' File: MAIN.BAS
DECLARE FUNCTION MyFUNC (A AS LONG, B AS INTEGER) AS INTEGER
$LINK "UNIT.PBU"
    X = MyFunc (arguments)
    ...

I suggest you re-check your procedure headers, and if you do not use explicit typing (either with AS or a type specifier)check any DEFxxx statements you have in use.

Regardless, if you use PBC with the RE option (find run-time error); you should
be able to then insert the correct debug code to write values to the screen or to disk.

One last thought.....
If you compile the UNITs without ERROR ALL ON and fail to have an ON ERROR GOTO in the unit code, errors in the unit code can reflect themselves as "mystery" errors when you return to the main module.
So you might want to recompile your units and make sure they have ERROR ALL ON.

MCM

**Jerry Mason** · 30 Nov 2000, 10:27 AM

Apologies to Lance, but I can't count the number of times that
I've added or moved $SEGMENT directives by a few lines just to
get working code.

And even if Mike Luther's analysis is wrong, his technique does work,
and deserves to be heard so others can benefit from it.

------------------

**Davide Vecchi** · 2 Dec 2000, 02:44 AM

Checking the procedures headers is a thing that i actually can' t do, so i' ll do it later, however it seems a good idea, thanks.

I also checked the situation you described, but it should not compile, and it doesn' t. Probably, PB detects that the parameter is mismatched. It gives a compilation error:
Error 481: Parameter mismatch - may need ByCopy: MYFUNC

This is the code i tried:

--------------------
' File: MAIN.BAS

$COMPILE EXE

$ERROR ALL ON

DECLARE FUNCTION MyFUNC (A AS LONG, B AS INTEGER) AS INTEGER

$LINK "UNIT.PBU"

PRINT MyFunc (1, 2)

END
--------------------
--------------------
' File: UNIT.BAS

$COMPILE UNIT "UNIT.PBU"

$ERROR ALL ON

FUNCTION MyFunc (A AS INTEGER, B AS INTEGER) PUBLIC AS INTEGER

MyFunc = A + B

END FUNCTION

END
--------------------

About using PBC with /RE, i get the same information i was getting with Find Error within the IDE.

<<
So you might want to recompile your units and make sure they have ERROR ALL ON.
>>
Really, i do have $ERROR ALL ON in each unit and in the main module.

**Wyman A Belts** · 2 Dec 2000, 07:08 AM

Hi Davide,
I was having some problems with some string arrays and I think
adding $Dynamic fixed it. Something to try anyway. Good Luck!!

------------------
[email protected]

**Mike Luther** · 2 Dec 2000, 11:14 AM

Mike ..

I hate to be a pest and .. what you said is correct and yet:

One last thought.....

If you compile the UNITs without ERROR ALL ON and fail to have an ON ERROR GOTO in the
unit code, errors in the unit code can reflect themselves as "mystery" errors when you
return to the main module.

So you might want to recompile your units and make sure they have ERROR ALL ON.

On page 24 of the manual, it explicitly states:

The error tests specified with this metastatement override the default
(ALL ON) ...

Further, since it specifically notes that the $ERROR metastatement should
only be used once ... in any module before any executable code, one
would, I hope, be able to conclude that the default state for all this
stuff is the ALL. You shouldn't have to do anything to have the services
of the error trapping for all of them in any UNIT you make.

Or is this garbled in the documentation? If I don't set it otherwise,
which I never have, and in the IDE compile window, they are all still
showing "ON" which I think is the default, why does anyone have to
hand include this in the header code to get the service?

Curious George here...

------------------
Mike Luther
[email protected]

**Michael Mattias** · 2 Dec 2000, 12:48 PM

The situation I was thinking of is the need for ON ERROR GOTO in the called module.

I have not worked much with PB/DOS for about a year, so my memory is hazy, but it seems I recall something about needing ON ERROR GOTO in the unit or you don't get the line-by-line checking that generates.

I am thinking this...

Code:

' UNIT.BAS
  FUNCTION Foo (X AS LONG) PUBLIC  AS INTEGER
   [really cool code goes here]
  END FUNCTION

'UNIT EUNIT.BAS

  FUNCTION Foo (X AS LONG) PUBLIC  AS INTEGER
   ON LOCAL ERROR GOTO somewhere
   [really cool code goes here]
  END FUNCTION

...that these two units compile differently. The second unit will immediately respond to a current "ON ERROR GOTO" trap in the calling module, but the first module won't.

Of course, I have been working with so many different compilers lately I'm not sure which way is up.

MCM

**Davide Vecchi** · 2 Dec 2000, 02:25 PM

The problem, for the moment, is solved by un-sharing the array IntestCMX_s$() the error occurred on. Instead of making it PUBLIC, it' s passed as a parameter to the procedures that need it. No errors occurr anymore (but the mines..).

I did put ON ERROR GOTO 0 in all the code modules (none had it, just some ON LOCAL ERROR). I still get an error 9 but at a different location, still on a 2D string array which is PUBLIC like the previous one, but this is in another unit.

Announcement

New Sub-Forum

Error compiling with PB but not with PBC

Error compiling with PB but not with PBC

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment