error in lclrescache with console app

[mtanner]

I've got a console app working ok. It does a lot of list manipulation by allocating list items with New, lots of pointer manipulation, the free everything up by Dispose(P).  But when the application closes, I get a

Exteral error:SIGSEGV
in file "lclrescache" at line 448.

This is with FOC Version 2.6.4
SVN revision 49931

Can anyone give me some hints about what might cause this error please?

[Thaddy]

Apart from the fact you are using an old and unsupported version of FPC:
The line is on entering a lock.
Set the global variable IsMultiThreaded to true in your lpr or program file.
From version 3.0.0 this is always true for Windows but this is not the case in fpc 2.6.4.
If you are using Linux add cthreads as one of the first entries to the uses clause in your program file.
Adding cthreads will also set Ismutithreaded to true. In newer versions e.g. 3.0.0 + this is done autmatically if you use a thread or use cthreads.

After that see what happens.

BTW: You are probably also using a list structure that is a bit old fashioned.
After upgrading you may want to look at the TList<T> in the FGL unit, or even TList<T> in rtl-generics, but that is only in trunk.

[mtanner]

Thanks for that.
I see the IsMultThreaded variable is in NSThread,inc, but I'm not sure how to include that in my application?

I get the impression that a lot of complex things are going on behind the scene with console apps. I'm very impressed with Lazarus and have converted major anounts of code to Lazarus. Most of my console apps are anciliary things like code generators and unit test rigs, but converting/writing Laz console apps is relatively less straighforward than GUI apps!

On the back-level comment. I was using a later version but backed out to an earlier one to avoid some minor problem with charts - can't remember what is was at the moment. I'll probably get back uo-to-date soon, at the end of my current tranche of development.
I hqad a look at TList, which looks interesting but I can't aford the learning curve just now - I have a large library of well-tested and complex list manipyulation routines, so at least for now I'm better off sticking with those as they are.

[mtanner]

I coded IsMultiThreaded instaead of IsMultThread!
But I still get an error at line 448 whether InMultiThread is set true or false.

I have other simple console apps that do not give this error, so it's a puzzle what feature of the problem program is causing the errro to appear. I am not using any multi-thread code as far as I know, so is it something to do with Heap management with all the New/Dispose of memory of the Heap?

[mtanner]

I installed 3.0.0. Still get problems.

External SIGSEGV
at address 00403C71 ( though I guess that does not mean much)

The code dump window is headed
SYSTEM_$$_FOC_CPUCODEINIT (234)
and the reported address is a few lines under a bold font lin "fpc_ansistr_decr_ref"

Does that enable any useful advice?

[lainz]

Search it in google:
https://www.google.com/search?q=fpc_ansistr_decr_ref

It happened to me when accessing a dll and the string was assigned in the dll, then the dll was freed and the reference too, so when I was trying to read that string that error happened, but can be more cases in what this happens

[mtanner]

Thanks. Digging around oin the web I got the imporession that the problem could be to do with strings, withinvalid references to ansistrings for example. However, my code uses entirely either "shortstring" of "string[nn]", so there should be no allocation of managed strings, and even in dynamically-assigned records with, say, a shorttring[60] as a field, then the string[60] field shoud be in the record and not created separately. My code ruins successfully, including deallocation (Dispose) of dynamically created list elements.

I'm now stuck. This is turning into one of those unexpected "trivial" programming problems that consume many hurs!

I'm thinking of changing all my lits-elements, which are currebtly "records" with a few fields, into "classes" just to see if that makes any difference - on the theory that it will use some different RTL code which may not have this problem.

[mtanner]

Judging by the number of typos I put in my last post it must be time to put the keyboard away.

But here's a surprise. Bya process of elimination I've found hot how to make the errror go away!

My program is for testing the parsing os a JSON-like input. For testing I hold the input code in a structire:

Const MaxJstrings=20;
Type PJInput=^TJInput; TJInput=array[1..MaxJStrings] of shortrstring;

The key bit of code is the "shortstring". With "shortstring" I get the error.
With "string[255]" instead, I still get the error. With "string[254]" the error goes away. Also with "string[100]" the error goes away.

The value of MaxJStrings seems to have no effect.

All I can think of is that this suggests an error in the way FPC is handling shortstrings, which does not seem very likely, but "when yiou have eliminated all other possibilities.." as Holmes said.

[Thaddy]

The limit is 255 not 254.

[lainz]

The limit is 255 not 254.

So he maybe in code is trying to access an index +1? That can cause the SIGSEGV?

[Thaddy]

If he is counting in BASIC style and starts with one instead of zero, yes, that's a possibility.
He probably forgot the length byte at element zero is not part of the payload.
The string itself is element 1 upto a maximum of element 255. Not 256.

[mtanner]

I am well aware that the useable length of a shortstring is 255, with 1 byte for length making a variable size of 256 bytes. String[255] should be exactly equivalent to shortstring.

Hence my puzzlement that string[254] instead of string[255] should make any difference.
I am actually not using any index beyond about 100. If it is me making an errror in the index used, then why would string[255] raise an error when string[254] does not?

I'm always willing to believe I have made a coding error, and will continue to check this out, but until then I believe my comments are accurate.

[balazsszekely]

You should try {$R+} and {$Q+} compiler directives.

[mtanner]

I will try those directives. I'm still thinking in Delphi mode, and not as familiar as I need to be with Lazarus debugging. In Delphi propject options there are some check boxes to get range and overflow checking on universally, which I always did when developing. I notice in Lazarus prpoject options there are similar check boxes, so will those turn on checking throughout the copiled code, without the need to put the {$R+} {$Q+} explicitly in each unit?i

[balazsszekely]

@mtanner

Yes, you can enable those directives globally in Project Options-->Compiler Options-->Debugging. If you are lucky, you can locate the exact line which causes the issue.