Recent

Author Topic: FPC internal exception  (Read 939 times)

440bx

  • Hero Member
  • *****
  • Posts: 4212
FPC internal exception
« on: May 20, 2024, 07:42:58 pm »
Hello,

This applies to the current release of FPC, i.e, v3.2.2.  when compiling the following unit:
Code: Pascal  [Select][+][-]
  1. {$MODESWITCH ADVANCEDRECORDS    ON}
  2.  
  3.  
  4. unit ErrorHandler;
  5.  
  6.  
  7. { --------------------------------------------------------------------------- }
  8. INTERFACE
  9. { --------------------------------------------------------------------------- }
  10.  
  11. type
  12.   TERROR_ID =
  13.   (
  14.    eid_no_error,
  15.  
  16.    eid_uninitialized_program_data
  17.   );
  18.  
  19. type
  20.   TERROR_STATE    = record
  21.     strict private
  22.       es_procname_last_entered : pchar;   { name of last entered function/proc}
  23.       es_error                 : TERROR_ID;
  24.  
  25.     public
  26.       procedure Init();
  27.       function  Errored()          : boolean;
  28.       procedure SetError(InErrorId : TERROR_ID);
  29.       procedure SetProcName(InProcName : pchar = {$I %CURRENTROUTINE%}};
  30.   end;
  31.  
  32.  
  33. var
  34.   ErrorState     : TERROR_STATE;
  35.  
  36.  
  37. { --------------------------------------------------------------------------- }
  38. IMPLEMENTATION
  39. { --------------------------------------------------------------------------- }
  40.  
  41.  
  42. procedure TERROR_STATE.Init();
  43. begin
  44.   es_procname_last_entered := nil;
  45.   es_error                 := eid_no_error;
  46. end;
  47.  
  48.  
  49. function TERROR_STATE.Errored : boolean;
  50. begin
  51.   result := es_error <> eid_no_error;
  52. end;
  53.  
  54. procedure TERROR_STATE.SetError(InErrorId : TERROR_ID);
  55. begin
  56.   es_error := InErrorId;
  57. end;
  58.  
  59. procedure TERROR_STATE.SetProcName(InProcName : pchar};
  60. begin
  61.   es_procname_last_entered := InProcName;
  62. end;
  63.  
  64.  
  65. end.

The compiler reports an internal exception:
Code: Text  [Select][+][-]
  1. [size=10pt]Verbose: Compiling ErrorHandler.pas
  2. ErrorHandler.pas(33,51) Error: Compilation raised exception internally
  3. Verbose: Compilation aborted
  4. Debug: An unhandled exception occurred at $00000001000B7860:
  5. Debug: EAccessViolation: Access violation
  6. Debug:   $00000001000B7860
  7. Debug:   $00000001000BB450
  8. Debug:   $00000001000BC0A9
  9. Debug:   $00000001000BC43E
  10. Debug:   $000000010015AC62
  11. Debug:   $00000001000E7344
  12. Debug:   $00000001000E6FDD
  13. Debug:   $00000001000E8A33
  14. Debug:   $00000001000EA924
  15. Debug:   $00000001000EAC47
  16. Debug:   $000000010017BFBE
  17. Debug:   $000000010017C624
  18. Debug:   $000000010017CE90
  19. Debug:   $00000001001601F2
  20. Debug:   $0000000100160EBD
  21. Debug:   $00000001000E669E
  22. Debug:   $000000010019D592
  23. Debug:
  24. Verbose: D:\fpcTrunk2\fpc\bin\x86_64-win64\ppcx64.exe returned an error exitcode[/size]

It does not like having the {$I %CURRENTROUTINE%} as the default value for an optional parameter.

ETA:

Just to be on the safe side, this is on Windows, specifically Windows 7, 64 bit using the 64 bit version of the FPC compiler executed by Lazarus 64bit v3.99

Anything else you want to know, just ask.


« Last Edit: May 20, 2024, 07:48:43 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

440bx

  • Hero Member
  • *****
  • Posts: 4212
Re: FPC internal exception
« Reply #1 on: May 20, 2024, 07:54:08 pm »
It's probably obvious what I was trying to accomplish.  Have the "SetProcName" automatically grab the function/procedure name of the function/procedure where it is being invoked.  It would be very convenient to make that work somehow.

So that's my question now: does anyone know a way that is acceptable to the compiler to have it feed the function/procedure name as a parameter value ?

thank you for your help.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10001
  • Debugger - SynEdit - and more
    • wiki
Re: FPC internal exception
« Reply #2 on: May 20, 2024, 07:55:28 pm »
It also fails if the "{$I %CURRENTROUTINE%}" is placed outside the class in the interface section...

And in both cases, I would ask what should it include? There can't be a current routine, outside of a routine? (not sure if the header of a routine is considered part of it for that particular directive).

Of course, it still shouldn't crash, but rather give an error....

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10001
  • Debugger - SynEdit - and more
    • wiki
Re: FPC internal exception
« Reply #3 on: May 20, 2024, 07:57:48 pm »
Have the "SetProcName" automatically grab the function/procedure name of the function/procedure where it is being invoked. 

I was thinking about 2nd guessing that... Because (if that code worked), I would expect it to include the name of the procedure that contains the directive. So always "SetProcName".

IIRC someone did once try that with macros, and that did not work either.

440bx

  • Hero Member
  • *****
  • Posts: 4212
Re: FPC internal exception
« Reply #4 on: May 20, 2024, 08:09:14 pm »
IIRC someone did once try that with macros, and that did not work either.
That's the kind of stuff that crosses the mind while coding and tried to see if by any chance it works (don't want to miss out on a good thing if it works.)

It was worth a try... didn't work... oh well.

but, as you said, it should emit an error not an internal exception.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10001
  • Debugger - SynEdit - and more
    • wiki
Re: FPC internal exception
« Reply #5 on: May 20, 2024, 08:22:14 pm »
Btw, depending on the underlaying needs....

If you did not plan on local debug logging, but rather something like printing traces "client side" at runtime, so people using your app can send in a (meaningful) trace for errors, then you don't need the names.

Well in most cases. If the target OS allows a non-relocating exe (Mac does not, but afaik Win and Linux do).
- Compile with debug info
- keep a copy with debug info
- create a stripped copy (must be from the same compiler run. Not just same source, but really same compilation)
- distribute the stripped copy
- use Leak-and-traces resolve button, to resolve address traces against the copy with debug info.

Test it before relaying on it.

440bx

  • Hero Member
  • *****
  • Posts: 4212
Re: FPC internal exception
« Reply #6 on: May 20, 2024, 08:59:18 pm »
Thank you Martin.

Like most everyone, I try to keep error handling as simple as possible (not always easy.) 

My preferred method so far, is to output the routine name and a number that identifies the error sequentially in the routine.  That way if the same error can occur more than once, both errors have different identifiers because one has to forcefully be before or after the other, hence have a different sequence number.

Fortunately, the program I'm currently working on is fairly simple and, doesn't require anything complicated.

Your mentioning macros gave me an idea.  The following works and comes reasonably close to what I originally wanted:

Code: Pascal  [Select][+][-]
  1. {$define _Entered:=ErrorState.SetProcName({$I %CURRENTROUTINE%})}
That macro along with the error management unit works great :)

All I need is to code "_Entered;" upon routine entry and the name is all set. 

To set the error (if any), I've got:
Code: Pascal  [Select][+][-]
  1. {$define _Errored:=ErrorState.SetError}

Prefixing the macro names with "_" also makes them stand out (and no other routine in my code is prefixed with "-", therefore that really makes the macros stand out.)

Now that I'm thinking about making the macros stand out, I might make them uppercase too.  They would be the ONLY non-type uppercase identifiers, since all the code is in lowercase, they would really stand out.

Thank you for the help and the mention of the macro... that definitely helped.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10001
  • Debugger - SynEdit - and more
    • wiki
Re: FPC internal exception
« Reply #7 on: May 20, 2024, 09:32:18 pm »
Interesting that this macro works, because IIRC (need double checking) someone tried that with the filename/linenumber, and it added the line number where the macro was declared, rather that where it was used.
Of course there is no routine where you declare the macro (I assume...)

Personally, I use a code template
Code: Text  [Select][+][-]
  1. debugln(['$ProcedureName() '|]);
The text is inserted, when I initially create the template. So it doesn't follow renames. And I can't copy and paste it.
Actually, I could just put the compiler directive there, and that would work (for me).
I don't mind, if it is longer text to read. It gets all auto inserted, so no work to type.

 

TinyPortal © 2005-2018