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}

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.

Vinzent wrote

.. 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

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.

Vinzent wrote

> 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

No. It is also meant for adding more information to the exception backtrace.

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.

The program needs to *know* the linenumber, otherwise it can't tell you. That's what option -gl is for: include linenumbers into executable.

Michael wrote

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

Thanks for explanation.

Wolfram