Seg Fault unless I Sleep(200)

[Schmitty2005]

I get a seg-fault unless I insert a

Code: Pascal  [Select][+][-]

1. Sleep(200);

in the code at the begining of the procedure.  There is a large dynamic array and a large record that are being used in a procedure as parameters.  I am thinking it has to do with the record more than the array.  I cannot post the code, there is just too much, and it is also WIP.  I may try to make a small example if I can duplicate without all the other code.

Here is the code with warning that this is just a hobby so this may look bad:
https://github.com/Schmitty2005/PascalWaveTools/tree/broken
This is where the seqfault happens :
https://github.com/Schmitty2005/PascalWaveTools/blob/b0355b7281ce8d549735e6e8d47429fd88a83c7b/mtwaveprocess.pas#L64

SYSTEM__$$__WAITFREE_VAR$PMEMCHUNK_VAR+1
crashing at :
0000000000419E87 488B92B8000000           mov rdx,[rdx+$000000B8]

I have tried with and without  VAR in the procedure parameters.
I know it is unlikley  to tell without code posted, but hopefully someone will have some ideas.

Any suggestions  as to why this happens ?  The code will also work if I set a breakpoint and continue. 

[Lulu]

I remember having this kind of error on a "SetLength(...).
It happened when I wrote procedure to manipulate audio data in buffer.

 The error was not at the line with the "SetLength(...)" but elsewhere: a procedure write more audio data than the buffer capacity, so memory block have been corrupted. It took me a while to find the cause...
I don't know if this is the same for your case. Just a suggestion.

[marcov]

What happens if you turn range checking and other runtime checks on?

[Schmitty2005]

What happens if you turn range checking and other runtime checks on?

All range checks (range, I/O, Overflow, stack , Verify Method Calls) are on, and no errors......

[Schmitty2005]

I remember having this kind of error on a "SetLength(...).
It happened when I wrote procedure to manipulate audio data in buffer.

 The error was not at the line with the "SetLength(...)" but elsewhere: a procedure write more audio data than the buffer capacity, so memory block have been corrupted. It took me a while to find the cause...
I don't know if this is the same for your case. Just a suggestion.

It does work just fine with Sleep(200) added, or a debug breakpoint.....It seems like the memory manager is not catching up for some reason....I can try a few things with the length and see if that helps....Thank you for the suggestion.

[Schmitty2005]

Just a note of interest, with all the debug checks set to OFF, this code compiles and runs.  The code is not complete enough to know if it works properly or not though. 

Is that to be expected under certain circumstances ?

EDIT:  More Specifically it is the Stack check (-Ct ) that is causing the issue.  It works fine when not used.

I am guessing this is because record types are on the stack and the debugger cannot catch up to what the program needs when stack checking is going on ?

Is this a bug ?   FPC 3.2.2 from Ubuntu 24.04 LTS repo and Lazarus 4.2 built from GIT

[jamie]

I see that you are not calling the inherited Constructor in the second overload in your Thread class.

I think it was the TmtWaveproc or something like that.

 In any case, you really should predefine a maximum array and use a size index instead of keep resizing it.

 Also, I noticed the code you posted can't be complete because you created threads using a local managed array and then supply no code to use them? Then the procedure comes to an end!

 Not sure what you had in mind, but something just does not look copasetic.

Jamie