Discussion:
[fpc-pascal] Unknown runtime error 202
Wolfram Kläger
2006-07-26 16:12:31 UTC
Permalink
I had this error two or three times these days. I managed to get rid of it by moving a local method variable to a field. Example:

class.method
var
d3 : array[ .., .., ..] of ...
begin
...

Works, if length(d3) < unknown limit. When I get the unknown runtime error 202 instead, I rearrange d3 to

... class
private
Fd3 : array ...

Then it works again. Apparently for unlimited array sizes. But what is the secret, where is the limit? And if this secret / limit is known, why the error is not?

Regards
Wolfram

P.S. I do love all fpc warnings and hints too. Except [file variable] does not seem to be initialized. So far the only situation, where I am used to wrap a statement in {$HINTS OFF} .. {$HINTS ON}
Vinzent Höfler
2006-07-26 16:34:59 UTC
Permalink
Post by Wolfram Kläger
I had this error two or three times these days. I managed to get rid
class.method
var
d3 : array[ .., .., ..] of ...
begin
...
Works, if length(d3) < unknown limit. When I get the unknown runtime
error 202 instead, I rearrange d3 to
... class
private
Fd3 : array ...
Then it works again. Apparently for unlimited array sizes. But what is
the secret, where is the limit? And if this secret / limit is known,
why the error is not?
Well, I don't know why exactly it is displayed as "Unknown runtime
error", but I hit that several times myself. Fortunately I still
remember the good old Turbo Pascal days, where number 202 was a stack
overflow error, and from my findings - when it happened to my code - it
still is. Highly recursive routines with a wrong or even missing
termination condition have never been a good idea. ;)

To answer your question: According to the documentation, the size of the
local variables (allocated on the stack) should not exceed 32 KiBytes
for portability reasons. So if you need more, it just depends on how
much the target architecture is able to supply.

So it's probably a better idea to allocate anything larger than that
from the heap.


Vinzent.
Wolfram Kläger
2006-07-27 12:05:50 UTC
Permalink
.. According to the documentation, the size of the
local variables (allocated on the stack) should not exceed 32 KiBytes
for portability reasons.
Thanks a lot. And I thought, I did RTFM often enough ...

BTW, do you know why exceptions donŽt return a line number? As I understand it, the except clause can return everything I want, when an exception occurs. I wished the compiler would throw the line number in addition to e.Classname and e.Message automatically.

Wolfram
Vinzent Hoefler
2006-07-27 12:18:44 UTC
Permalink
Post by Wolfram Kläger
.. According to the documentation, the size of the
local variables (allocated on the stack) should not exceed 32
KiBytes for portability reasons.
Thanks a lot. And I thought, I did RTFM often enough ...
BTW, do you know why exceptions donŽt return a line number?
Because you forgot to include the "-gl" switch for automatically
including the line info unit?

If you do that, the backtrace usually consists of procedure names and
line numbers instead of just addresses.


Vinzent.
Wolfram Kläger
2006-07-27 13:15:04 UTC
Permalink
Post by Vinzent Hoefler
Post by Wolfram Kläger
BTW, do you know why exceptions donŽt return a line number?
Because you forgot to include the "-gl" switch for automatically
including the line info unit?
As I understand it, this option is only helpful when you are struggling with the debugger. My question is: What is the problem to throw the line number on the console as well as e.message, e.classname and everything else specified in the except clause, e.g. the contents of a local variable named LastLineDone?

Wolfram
Michael Van Canneyt
2006-07-27 13:21:35 UTC
Permalink
Post by Wolfram Kläger
Post by Vinzent Hoefler
BTW, do you know why exceptions don?t return a line number?
Because you forgot to include the "-gl" switch for automatically
including the line info unit?
As I understand it, this option is only helpful when you are struggling with the debugger.
No. It is also meant for adding more information to the exception backtrace.
Post by Wolfram Kläger
My question is: What is the problem to throw the line number on the console as
well as e.message, e.classname and everything else specified in the except
clause, e.g. the contents of a local variable named LastLineDone?
Because you need the debug information for that. Hence the -gl switch.
It adds a HUGE amount of data to your executable, which is why it is not
included by default.

FileName/Linenumber info is only available through debug information.
It's not an interpreted language, but compiled language.

Michael.
Burkhard Carstens
2006-07-27 13:24:45 UTC
Permalink
Post by Wolfram Kläger
Post by Vinzent Hoefler
Post by Wolfram Kläger
BTW, do you know why exceptions donŽt return a line number?
Because you forgot to include the "-gl" switch for automatically
including the line info unit?
As I understand it, this option is only helpful when you are
struggling with the debugger. My question is: What is the problem to
throw the line number on the console as well as e.message,
e.classname and everything else specified in the except clause, e.g.
the contents of a local variable named LastLineDone?
The program needs to *know* the linenumber, otherwise it can't tell you.
That's what option -gl is for: include linenumbers into executable.
Wolfram Kläger
2006-07-27 14:55:34 UTC
Permalink
.. FileName/Linenumber info is only available through debug information.
It's not an interpreted language, but compiled language.
Thanks for explanation.

Wolfram

Continue reading on narkive:
Loading...