Possible FPC Compiler Change?

[JohnK]

Recently, I was trying to debug a SIGSEGV problem I was having at runtime with the following code segment:

Code: [Select]

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure Call_ooRexxSAA();
Const
  TextVal: PChar = 'These words will be swapped'; // text to swap

var
  PRxArgs: PRxString = nil;
  RC: Cardinal = 0;                               // return code from REXX
  RxRc: Integer = 0;                              // return code from function
  RxArgs: RxString = (strlength:0; strptr:nil);   // argument string for REXX}
  RxResult: RxString;                             // result value from REXX
  RexxStart_RC: Cardinal = 0;                     // Save RexxStart return code

begin
// By setting the strlength of the output RXSTRING to zero, we
// force the interpreter to allocate memory and return it to us.
// We could provide a buffer for the interpreter to use instead.

  RxResult.StrLength:=0;                          // initialize Result to empty
  MakeRxString(RxArgs, TextVal, StrLen(TextVal)); // create input argument
  PRxArgs:=@RxArgs;

// Here we call the interpreter.  We don't really need to use
// all the casts in this call; they just help illustrate
// the data types used.
  RC:=RexxStart(1,                // number of arguments
                PRxArgs,          // array of arguments
                'backward.fnc',   // name of REXX file
                nil,              // No INSTORE used
                'FNC',            // Command env. name
                RXSUBROUTINE,     // Code for how invoked
                nil,              // No EXITs on this call
                RxRc,             // Rexx program output
                RxResult );       // Rexx program output
  RexxStart_RC := RC;end;

procedure TForm1.Invoke_ooRexxSAA(Sender: TObject);
begin
  Call_ooRexxSAA();
  Click_cnt := Click_cnt + 1;
  Form1.Msg1.Caption := 'ooRexxSAA called ' + IntToStr(Click_cnt) + ' times' ;
end;

I know the above code is in error as it generates a runtime SIGSEGV error because in procedure TForm1.Invoke_ooRexxSAA executes the Call_ooRexxSAA() statement, it does NOT pass the Sender: TObject parameter.  Then in the Call_ooRexxSAA procedure when it tries to reference ANY of these statements:

•   Form1.Int_RC.Caption := 'Interpreter RC: ' + IntToStr(RexxStart_RC);
  
•   Form1.Func_RC.Caption := 'Function RC: ' + IntToStr(RxRc);
  
•   Form1.String_In.Caption := 'String In: ' + StrPas(RxArgs.strptr);
  
•   Form1.String_Out.Caption := 'String Out: ' + StrPas(RxResult.strptr);
  

it does NOT have access to any of the Form1 fields because they are not locally defined or passed to this procedure.
However, when I compile this code, I do NOT get any error or warning messages telling me that any of these variables are not available.  I only get a runtime error (SIGSEGV) which does not indicate which variable or variables is causing the error.

It seems to me, if at all possible, that this type of error could be detected at compile time and appropriate warning or error messages supplied to alert this problem to the programmer.  Providing a compile time error rather than a runtime error would certainly be more programmer friendly and possibly prevent a huge number of trips to the Lazarus Forum to search for or open new problems related to this type of programming error.

Is there some reason that the FPC compiler could not or even should not be changed to detect this type of error??

As best as I can tell, this is already done for other variable types that are not globally or locally defined.  Is there something special about Form object variables that prevents this type of detection?

[Leledumbo]

I know the above code is in error as it generates a runtime SIGSEGV error because in procedure TForm1.Invoke_ooRexxSAA executes the Call_ooRexxSAA() statement, it does NOT pass the Sender: TObject parameter.

Not required. Sender is no magic, it's just sent indicating which object triggers the event. Calling a method expecting Sender with nil is perfectly fine, as long as the method itself doesn't try to access Sender or at least checks whether Sender is nil.

it does NOT have access to any of the Form1 fields because they are not locally defined or passed to this procedure.

Learn identifier scoping. Your code is perfectly valid, Form1 fields are accessible because you access it through Form1 object.

However, when I compile this code, I do NOT get any error or warning messages telling me that any of these variables are not available.  I only get a runtime error (SIGSEGV) which does not indicate which variable or variables is causing the error.

Remove Form1. from your code, you will get the compile error.

Is there some reason that the FPC compiler could not or even should not be changed to detect this type of error??

As best as I can tell, this is already done for other variable types that are not globally or locally defined.  Is there something special about Form object variables that prevents this type of detection?

This is a common problem for people learning Object Pascal from top to bottom approach using the GUI and form designer to learn, instead of the basic syntax and semantics. I suggest you read the Free Pascal manual first and when you have managed to master the OO concept, learn LCL application flow. How application is started, how a form is created and maintained automatically, its lifetime, etc.

[JohnK]

Learn identifier scoping. Your code is perfectly valid, Form1 fields are accessible because you access it through Form1 object.

I read about identifier scoping, but IMO I don't think the compiler follows the documentation.  In the code I have presented in this topic, I tried many different things to prevent the SIGSEGV runtime error and nothing worked until I move the assignment statements from the call_ooRexxSAA function into the Form1.Invoke_ooRexxSAA function.  And because I understand identifier scoping some, I knew that I had to move some of the call_ooRexxSAA locally defined variables into the global defined variable area.  And those changes made my program work and I no longer got the SIGSEGV error.

Also when I opened my original SIGSEGV runtime error (which used the coding show in this forum topic) in a different forum area, you tried to review my problem and the code I had, but you never provided a successful solution. You did state that I might have a local variable problem that was causing the SIGSEGV eror.  But you never suggested that I try what I ended up doing to get my program to work.  So if I believe what you are saying now and that my original code (as shown in this topic) should have worked AND that my assumptions stated in this topic (that I had to pass the SENDER: TOBJECT parameter) is also incorrect, then my only conclusion can be is that the FPC compiler has some sort of error that prevents my "perfectly valid" code from working and causes it to fail with a SIGSEGV error.

Also if the assertions I make in this topic when I set it up are so incorrect, and you indicate that "Your code is perfectly valid" and the "Form1 fields are accessible", then why did my code not work as shown in this topic??

I suggest you read the Free Pascal manual first and when you have managed to master the OO concept, learn LCL application flow. How application is started, how a form is created and maintained automatically, its lifetime, etc.

I did read the Free Pascal manual first or I never would have gotten as far as I did.  While the manual is not bad, it certainly is not a definitive, full discussion of the Free Pascal language.  I have read several books concerning Visual Basic and Visual C++ and both of them are much fuller and complete and contain many, many more coding examples!

Also, where is the Lazarus documentation?  As best as I can tell, the only Lazarus documentation is in HTML format and HTML format takes hours and hours to read and provides horrible access for actually studying it, IMO.  I printed off the FPC manual, read it, and referred back to it several times and while it does have a lot of information, it did not help me get around my SIGSEGV error  I was having and have documented in my topic.

I'm sorry if my comments seem critical and I apologize if you think they are, but I worked hard for several days trying to get this code to work before submitting the original Forum topic.  It my comments here bother you too much, feel free to expunge the topic and we can just agree to disagree on this.  I will stumble through and get my FPC programs to work or switch to another language that is easier and better document with examples.

[marcov]

If you want to find compiler bugs, the first thing to let go is assuming that non crashing code is valid code.

The extra hidden parameter of the method might simply alter register allocation a bit, or allocate a few more temps that avoids the worst of the stack crash.

IOW exceptions going away is no sign of correct code.

[minesadorada]

...

Also, where is the Lazarus documentation?  As best as I can tell, the only Lazarus documentation is in HTML format and HTML format takes hours and hours to read and provides horrible access for actually studying it, IMO.  I printed off the FPC manual, read it, and referred back to it several times and while it does have a lot of information, it did not help me get around my SIGSEGV error  I was having and have documented in my topic.

...

Have you looked at the wiki? http://wiki.freepascal.org  There are lots of code examples there.

[Leledumbo]

I read about identifier scoping, but IMO I don't think the compiler follows the documentation.  In the code I have presented in this topic, I tried many different things to prevent the SIGSEGV runtime error and nothing worked until I move the assignment statements from the call_ooRexxSAA function into the Form1.Invoke_ooRexxSAA function.  And because I understand identifier scoping some, I knew that I had to move some of the call_ooRexxSAA locally defined variables into the global defined variable area.  And those changes made my program work and I no longer got the SIGSEGV error.

Also when I opened my original SIGSEGV runtime error (which used the coding show in this forum topic) in a different forum area, you tried to review my problem and the code I had, but you never provided a successful solution. You did state that I might have a local variable problem that was causing the SIGSEGV eror.  But you never suggested that I try what I ended up doing to get my program to work.  So if I believe what you are saying now and that my original code (as shown in this topic) should have worked AND that my assumptions stated in this topic (that I had to pass the SENDER: TOBJECT parameter) is also incorrect, then my only conclusion can be is that the FPC compiler has some sort of error that prevents my "perfectly valid" code from working and causes it to fail with a SIGSEGV error.

Also if the assertions I make in this topic when I set it up are so incorrect, and you indicate that "Your code is perfectly valid" and the "Form1 fields are accessible", then why did my code not work as shown in this topic??

Something else causes it, and as Marco pointed, your exception is now gone is not a sign that your code is correct. It could be a luck instead. I'll try installing rexx library to be able to link your project, I hope it's not big because it won't have any other use for me and would be a waste of space. Have you tried getting stack trace anyway? Let the exception happens, and open call stack window. Or simply run it from terminal (uncheck -WG if you're on windows so you can copy paste from cmd window), additionally with --debug-log=somefile.txt to get LCL log messages, too. If your debugging info settings are correct, you should be able to see what went wrong.

I did read the Free Pascal manual first or I never would have gotten as far as I did.  While the manual is not bad, it certainly is not a definitive, full discussion of the Free Pascal language.  I have read several books concerning Visual Basic and Visual C++ and both of them are much fuller and complete and contain many, many more coding examples!

Also, where is the Lazarus documentation?  As best as I can tell, the only Lazarus documentation is in HTML format and HTML format takes hours and hours to read and provides horrible access for actually studying it, IMO.  I printed off the FPC manual, read it, and referred back to it several times and while it does have a lot of information, it did not help me get around my SIGSEGV error  I was having and have documented in my topic.

Lazarus documentation ATM is only the wiki, the HTML/CHM is an API reference. By learning, I don't mean reading documentation only, you can trace the code by yourself as well. I admit Lazarus lacks such a documentation as FPC has (which you're still not satisfied as well).