weird errors

[David Venable]

I can't really post example code right now because
my program is around 1300 lines long and I haven't
gotten the same result from isolating anything. I'm
just wondering if this is a known bug or if anyone
has experienced this before. I'm using pb 3.1 and
the function where the error occurs is recursive.

When I place the variable 'inif', which is an integer,
in the watch window and then step through the program
I get:

inif: Syntax Error

this occurs with a few different variables, but not
all. Thanks for any help. If I can isolate some
code that causes the same problem, I'll post it.

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

[Lance Edmonds]

First, do you have $ERROR ALL ON in your code? Since the Function is recursive, have you made the stack size large enough to cope with it?

Next, if you print the variable to a file (rather than watching it in the debugger), does it's value show as being correct?

Basically, my feeling from your brief description is that it could be a memory corruption problem due to errant code writing beyond an array boundary, or some other memory-relaated issue. It could also be a memory manager problem... what platform and EMS/XMS manager are you using?

IHTH!

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

[Davide Vecchi]

I don’ t know if this will help nor if it applies to 3.1, however, just to be watching the var in the reccomended way, make sure you are asking to watch inif% (from the PB/DOS 3.5 help:

When selecting a PowerBASIC variable to watch, you must always append a type specifier, even if your source code doesn't require one

).

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

[David Venable]

Thanks Lance and Davide. It turned out to be the stack,
but all is working well now. I appreciate the help.

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

[Mike Luther]

Not only is it, per the book, that you have to specify the variable
type to watch it, but specifying the variable type on **ALL** of
them throughout the source is, to me, helpful!

Not only is it so much simpler to keep track of all of them as
to what they are, visually, but there is a hidden benefit!

If, for some oblique reason, one wants to port the source to,
say, C++ or C .. you can then let the translator make a
common coding technique pass.

You can tell the translator to append an ".int" to all the source
instead of that "%", or use ".lng", for the "&" and voila! Instant
ability to carry that same comforting quick look familiarity with
your 'same-name' variable in C or C++!

Until you've faced it, you have no idea how comforting it is to be
able to 'visualize' variables at sight in four times the total
source code slurry, as opposed to our WONDERFUL overview we have
in PowerBASIC ...



If my foggy memory is correct, I think it was the Microsoft folks
in the Visual Basic world, that wanted to focus throwing away these
variable types in the source on a source-wide basis. The 'desired'
position, I think I recall, was to do all this declaration at the
top of the program, then not carry them afterward!

I could be totally wrong in that memory.

But when yo get up to 700-2000 variables per program, it sure seems
a lot easier to be able to instantly spot of what kind they are.
It also makes it, to my view, far easier to keep from making the
error of calling it one kind of variable in one place in the code,
then getting off a few nested SUB's deep in it, and getting it
wrong by 'default' of in a SUB or function...

Just $.02 worth here...


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

[Pat Bruening]

Dave,
I recently encountered the same type of error in the watch
variables. It turned out that the problem was with non-nested
IF...THEN statements. When I put each IF on its own line, the
problem disappeared. Thus I tried to put code similar to this:
x=int(str$(value)):if x <1 then ....
The if clause was on the same line as the "x=int...". When I put
the IF clause on its own line, the problem disappeared. I hope
this also helps.
Pat

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

[Lance Edmonds]

Mr Bruening,

Please avoid posting such anecdotal stories....

If you have some code that shows the problem you casually describe above, then we would like to see it. There has NEVER (I repeat) NEVER been a single bug reported with IF/THEN statements IN ANY SHAPE OR FORM. Your message suggests problems that just do not exist.

The problem David described to us was due to a stack overflow, as he reported 2 days ago.

Thank you.

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

[Davide Vecchi]

Pat, often problems like the one you mentioned are due to memory corruption (OS, memory managers etc.), so IMO a possible explaination might be that merging two or more lines into a single one, occupied memory locations changed in a way that didn’ t cause the corruption anymore.
It’ s that thing of when such problems disappear by simply moving parts of code from one place to another, which i think many of us experienced. I also experienced more than once these disappearings even just compiling on a different PC the *same* code with the same compiler settings.

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

[Mike Luther]

Lance ..

Mr Bruening,

Please avoid posting such anecdotal stories....

If you have some code that shows the problem you casually
describe above, then we would like to see it. There has NEVER
(I repeat) NEVER been a single bug reported with IF/THEN
tatements IN ANY SHAPE OR FORM. Your message suggests
roblems that just do not exist.

The problem David described to us was due to a stack
verflow, as he reported 2 days ago.

You might recall that I posted this same statement a long, long
time ago in relation to large programs. I've posted it and
variations on this theme more than once. And been chastised
also for it as .. "Your memory manager is faulty.

I admit memory managment for us all is a problem, Lance. But
I've asked, and never been told, exactly what the 'standard' is
to which we must comply for these things in order to run
PowerBASIC in an approved manner on an approved system.

Thus we all must somehow, get along, to help each other. It is
a two way street.

And it is TERRIBLY difficult to submit these to you folks,

However.....

On this last Internal Error 611 that prompted my latest post,
it is triggered by precisely what he I think he complains about.

If you simply change an IF / THEN construct as a multi-line form
to a single line in line form .. the error vanishes.

***********************

Now .. if you will kindly assure us that you won't ridicule me
for my miserably written code and that we are all truing to solve
this, I'll send you a common include file with about 600 public
variables and 3970 odd lines of code which, at least here do
just about what he says.

***********************

In *THIS* case, it produces an error 611.

I can tell you precisely the numeric line lable which makes it
happen, in this example.

I can absolutely guarantee you that in other cases, it can take
hundreds of hours of time to find out where in the Devil the thing
goes wrong, and when it does, you and others are correct, memoru
is corrupt. A variable that is needed at that point will be
corrupt. But the code will continue to execute, even with the
wrong value for the variable. And depending on whether the error
in the value is fatal or not, you either will abend the program
as a result of that one way or another, or .. your customer will
abend if the result is fatal to he or she.

I think that all code contains the propensity for errors.

I'll be perfectly happy to be proved wrong if I'm wrong and write
code badly.

I make more mistakes than I'll bet anyone here makes.

Should I submit this one in his, perhaps, defense?

From a production standpoint, after taking another twenty or so
hours of my life to trace it. I 'solved' the problem here when
I simply added about three lines of other code somewhere else
and the problem went away on its own.

Which is exactly what most of us are doing which hit this.

But I will try for us all if it's wanted and I won't get poked
with too sharp a stick for my miserable code..

In this case I was, after all these years, to *FINALLY* save a
single source code module for a single PBU, which only has
the one common include file in it .. which illustrates this
problem as seen here...

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

[Pat Bruening]

Lance Edwards!

I was just trying to help, not critize IF..THEN. I'm sorry
I ruffled your feathers.

Pat

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

[Mike Luther]

Pat

I've gone ahead and submitted the entire source display that
evokes what I think you see. At least it, or a variation of it
does here. And furthermore, it produces an internal 611 error
code during compile time.

The code submitted can't be executed to show what happens when
the thought to be true error actually gets involved in code
execution.

That'a a *HUGE* job to illustrate, at least in my experience.
More important, and this is just a personal opinion based on
years of watching this difference of opinion, is something else.

It isn't in my experience, so much a factor of how EMS, and other
upper memory is put together on a box, which successsfuly runs the
code that counts, as it is when something abends in the code that
makes it break.

That's just an opinion.

Code which DOES work, seems to be a non-problem on many different
boxes with many different implementations of upper memory. It
seems, at least in my case not to be so important. On the other
hand when something goes wrong in the code, which, indeed can and
seems to be related to the toolset; how the program collapses into
what is the eventual failure we see ... may vary widely between
how EMS is set up, and what all else is involved such as operating
systems. Yes and even operating systems of the same general kind
as well as just different levels of them.

Lance has complained that it hasn't been shown so. There are by
my internal Email holdings, a substantial number of others who
feel that it is.

Thus regardless of whether or not 'e wants to beat me over it all
I've gone ahead and just sent the code to show up the 611 part of
this which I do see here.

We'll worry about what to do next on the basis of what that produces.

If I have to be the sacrificial goat, so be it.


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

[Davide Vecchi]

Mike, i don’ t want to criticize you indeed (i think the contents of your posts are always very interesting, i learn a lot from them and i hope you keep them on), but i must say that you looked too hurried in candidating yourself as a victim. It’ s true that sometimes we saw insulting or offending posts here, made by people who just didn’ t like the subject discussed in the topic, but as far as i remember, these always came from people external to PB.
More important, on the other side, i saw posts made by users (included me, darn! ) resulting, intentionally or not, into a so unpleasant feeling that they simply had to be shot, but PB moderators professionally kept theirselves from replying in a corresponding unpleasant way.

I can assure that the only one time (out of a lot) when i have been able to make a variable watching problem replicable on different systems and i could put PB into the condition of replicating it, they gave me the most clear and useful feedback they could, and did all but making a victim of me.

I think the problem is that these forums, for which we should never get tired to thank PB, might negatively affect the image of PB products when a post, usually not by malice but by too approximative or emotional words, indirectely suggest the existence of bugs which aren’ t such. It’ s easy to happen because words are a rough approximation of thought in their nature, that’ s the main reason why IMO they should be used lightly and sparingly.

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