Lazarus

Using the Lazarus IDE => Debugger => Topic started by: Aruna on October 25, 2024, 04:04:47 am

Title: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 04:04:47 am
Hi everyone,

I'm working on a simple Lazarus project, and I'm using Assert() statements to catch unexpected conditions in my code. However, when an assertion fails, the program terminates, and I'm unable to step into the Assert() function to examine the context around the failure directly. I want to understand better what’s causing the assertion to trigger by being able to step through it in the debugger.

Does anyone know if it’s possible to configure Lazarus or use a specific debugging technique to step into Assert()? Or is there a way to see more context about the failed assertion beyond the termination message? What would be ideal is to be able to single-step through Assert() and any related code.

A simple code example is below that demonstrates the problem.


Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4. {$ASSERTIONS ON} // or equivalently {$C+}
  5.  
  6. interface
  7.  
  8. uses
  9.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
  10.  
  11. type
  12.  
  13.   { TForm1 }
  14.  
  15.   TForm1 = class(TForm)
  16.     Button1: TButton;
  17.     procedure Button1Click(Sender: TObject);
  18.   private
  19.  
  20.   public
  21.  
  22.   end;
  23.  
  24. var
  25.   Form1: TForm1;
  26.  
  27. implementation
  28.  
  29. {$R *.lfm}
  30.  
  31. { TForm1 }
  32.  
  33.  
  34. procedure TestDivision(a, b: Integer);
  35. var
  36.   result: Integer;
  37. begin
  38.   // Assert that the denominator is not zero before dividing
  39.   Assert(b <> 0, 'Error: Division by zero!');
  40.  
  41.   result := a div b;
  42.   WriteLn(a, ' divided by ', b, ' equals ', result);
  43. end;
  44.  
  45.  
  46. procedure TForm1.Button1Click(Sender: TObject);
  47. begin
  48. try
  49.    WriteLn('Testing division:');
  50.    TestDivision(10, 2);   // Works fine
  51.    TestDivision(10, 0);   // Will trigger assertion failure
  52.  except
  53.    on E: Exception do
  54.      WriteLn('Exception: ', E.Message);
  55.  end;
  56. end;
  57.  
  58. end.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Thaddy on October 25, 2024, 06:20:14 am
I would first get rid of using a plain exception if what you want is a specific EAssertionFailed exception.
Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. begin
  3. try
  4.    WriteLn('Testing division:');
  5.    TestDivision(10, 2);   // Works fine
  6.    TestDivision(10, 0);   // Will trigger assertion failure
  7.  except
  8.    on E: EAssertionFailed do
  9.      WriteLn('Exception: ', E.Message)
  10. else
  11.   raise;// it is not an assertion.
  12.  end;
  13. end;
or something along that line;
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Joanna on October 25, 2024, 06:38:26 am
Aruna and I were discussing assert () in chat.
Neither of us could step into it. I don’t know if it’s the fault of the gdb or assert is intentionally off limits?
Hovering over assert () doesn’t allow me to click on link to the source code like other things do.

When I tried to use assert in my project it does indeed stop the program with a dialog giving the line number of error and a gump to choose break or continue. Break takes me to spot where error occurred which Is good.

If I continue there is another gump for abort or risk data corruption.

So for debugging I guess it works ok but why am I not allowed to trace into it to see what it’s doing? I want to see how it gets the line number of error and such.

I have opted to use my own version of error checking that shows message and halts because assert requires too much gump clicking  %)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 09:19:28 am
What do you mean "step into assert"?

If you indeed want to see what assert itself does, then you need to build an fpc (an rtl) with debug info. (e.g. using fpcupdeluxe).
It is in system.inc
Code: Pascal  [Select][+][-]
  1. Procedure fpc_assert(Const Msg,FName:Shortstring;LineNo:Longint;
  2.    ErrorAddr:Pointer); [Public,Alias : 'FPC_ASSERT']; compilerproc;
  3. begin
  4.   if codepointer(AssertErrorProc)<>nil then
  5.     AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
  6.   else
  7.     HandleErrorAddrFrameInd(227,get_pc_addr,get_frame);
  8. end;
  9.  

Mind that this is an intrinsic. As you can see the boolean result of the condition is not in the parameters => that code is inlined into your calling procedure. So the above is only called, if the condition fails.

Afaik it then depends. If any unit in your app (including recursively any unit you used) uses "SysUtils then it throws an exception.

And if you want you can catch that exception.



Most of the time the assert is simply used to alert of the error, and then meant to stop the exe.

Otherwise use "if ... then raise exception.create();"
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 09:24:41 am
I checked earlier (since that was my first thought), and even if FPC is built with full debugging the IDE doesn't step into Assert().

Presumably this is because- as you say- Assert() is a compiler/RTL intrinsic. I didn't check whether setting a breakpoint inside the RTL would do it.

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 09:37:14 am
It does step in. But only if the condition is true. The condition itself is inlined into the caller..
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 10:27:49 am
Ah :-)

So presumably if somebody wants to explore what's actually happening they insert a dummy Assert() with the condition negated.

Would this do anything at all if the condition was entirely evaluated at compilation time, e.g.

Code: Pascal  [Select][+][-]
  1. Assert( { not } SizeOf(Longword) = 2), ... )
  2.  

I've actually got quite a lot of size-checking assertions, particularly when checking that a data structure defined in e.g. an I2C or SPI interface unit is what's known in the C original.

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Joanna on October 25, 2024, 12:24:31 pm
What I did was placed a breakpoint in Lazarus on same line as assert and then tried to step into it using the ide.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 12:29:46 pm
What I did was placed a breakpoint in Lazarus on same line as assert and then tried to step into it using the ide.

Same as I did.

But I also did:
- make sure the condition was false
- my RTL had full debug info (that needs to be done outside the IDE)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Joanna on October 25, 2024, 12:51:10 pm
I used assert (false = true,’false = true);
 Which definitely ended the program after two different dialogs were clicked.
What was behavior of yours?
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 12:54:37 pm
- my RTL had full debug info (that needs to be done outside the IDE)
Hi @Martin_fr and 'how' does one do this please?

EDIT: make all OPT="-g -gl ?
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 01:02:42 pm
- my RTL had full debug info (that needs to be done outside the IDE)
Hi @Martin_fr and 'how' does one do this please?

FpcUpDeluxe.

Well that or download the sources, and play with Makefiles. (I don't have a link to any instructions)


Either way, you get a 2nd independent install of FPC => once you got that in the IDE you need to change the compiler (Tools > options // or if you prefer in the project settings, something like compile commands)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: TRon on October 25, 2024, 01:07:31 pm
EDIT: make all OPT="-g -gl ?
afaik it is make all DEBUG=1
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 01:12:07 pm
EDIT: make all OPT="-g -gl ?
afaik it is make all DEBUG=1

If you use FpDebug in your IDE I would suggest   OPT="-gl -gw3 -O-1"

-gl is not strictly needed. The info is added with -gw3
And the unit will be added if you compile the project with -gl

Of course if you want nice dumps when the compiler itself crashes => then yes: -gl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 01:57:05 pm
If you use FpDebug in your IDE I would suggest   OPT="-gl -gw3 -O-1"

-gl is not strictly needed. The info is added with -gw3
And the unit will be added if you compile the project with -gl

Of course if you want nice dumps when the compiler itself crashes => then yes: -gl

I routinely build FPC with -O- -gl and- as I said earlier- I couldn't step into an arbitrary assertion. However I didn't try both states of the controlling predicate.

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 02:51:22 pm
FpcUpDeluxe.
I have never used FpcUpDeluxe

Well that or download the sources, and play with Makefiles. (I don't have a link to any instructions)
Yes I usually build from source I find that is easier for me.

Either way, you get a 2nd independent install of FPC => once you got that in the IDE yo u need to change the compiler (Tools > options // or if you prefer in the project settings, something like compile commands)
Thanks Martin I will explore this further when I have time.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 02:52:46 pm
EDIT: make all OPT="-g -gl ?
afaik it is make all DEBUG=1
Thank you @TRon I will experiment with all the options and get back to you..
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 02:54:29 pm
EDIT: make all OPT="-g -gl ?
afaik it is make all DEBUG=1

If you use FpDebug in your IDE I would suggest   OPT="-gl -gw3 -O-1"

-gl is not strictly needed. The info is added with -gw3
And the unit will be added if you compile the project with -gl

Of course if you want nice dumps when the compiler itself crashes => then yes: -gl
I am running linux debian and I went with the default settings when I first installed so I think what I have in the IDE is gdb. How do I change this to FpDebug?
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 03:01:07 pm
I am running linux debian and I went with the default settings when I first installed so I think what I have in the IDE is gdb. How do I change this to FpDebug?

IDE, Tools -> Options -> Debugger -> Debugger backend -> Change type

I think.

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 25, 2024, 03:03:16 pm
I am running linux debian and I went with the default settings when I first installed so I think what I have in the IDE is gdb. How do I change this to FpDebug?

IDE, Tools -> Options -> Debugger -> Debugger backend -> Change type

I think.

MarkMLl
Thank you Mark.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 03:11:39 pm
I am running linux debian and I went with the default settings when I first installed so I think what I have in the IDE is gdb. How do I change this to FpDebug?

IDE, Tools -> Options -> Debugger -> Debugger backend -> Change type

Not "change type".

Select from the drop button in the toolbar (toolbar on top of the frame).

If not in there, then "add".

That way you can easily change later.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 05:14:39 pm
Sorry, I think I've been caught by that one before.

It's not exactly intuitive though...


MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 05:46:40 pm
Sorry, I think I've been caught by that one before.

It's not exactly intuitive though...

How to make it more intuitive?

If you click the "change type" a red warning appears, telling you to use "add" instead.

Changing the type can however be useful in some scenarios. When you have a gdb debugger and want to turn it into a gdb server, changing the type will preserve all options (from the grid) that they both share. Of course "copy" and the "change type" may be an even better idea.
gdb and fpdebug hardly share any options. So change type between them is not of much use. It will work though. But you should then also change the name or it gets confusing.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 07:30:19 pm
How to make it more intuitive?

I'm sorry, that sounded excessively critical. It's just that irrespective of whether that top line is a menu or the tabs on a multipage control (without the visual hint of tab outlines), it's unusual to get a dropdown in the same place. A bit of a mixed metaphor...

Quote
Changing the type can however be useful in some scenarios. When you have a gdb debugger and want to turn it into a gdb server, changing the type will preserve all options (from the grid) that they both share. Of course "copy" and the "change type" may be an even better idea.
gdb and fpdebug hardly share any options. So change type between them is not of much use. It will work though. But you should then also change the name or it gets confusing.

Yes, and using a gdb server is about the only way of debugging something that runs as root (or with enhanced capabilities).

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 25, 2024, 07:43:39 pm
Sorry on getting off topic...

I'm sorry, that sounded excessively critical.

It didn't, not at all.
And you are not the only one who got that wrong.

So I am genuinely looking for answers how to improve it.

It seems there is a similar issue on the "user defined markup" with adding lists (aka groups).

Yet, on the Display>Colors page, it does seem to work. Or maybe people rarely need to change stuff in the toolbar?
Though on 2nd thought the color|priority buttons may not be well known, but then that is expert territorial.



The drop-buttons could probably be replaced by real comboboxes. Not sure if they will stick out like a sore thumb, but maybe that is exactly what they need to do?
And then they don't expand to the length of their content....

Maybe just give the thing a diff color, but changing colors always goes wrong when users meddle with the IDE colors (suck as dark theme)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: MarkMLl on October 25, 2024, 07:59:19 pm
I don't think that many people fiddle with the colours, or with keyword etc. markup (noting the recent thread, which seemed to be new ground for a lot of people).

Looking at those various setup pages, I suspect that on the others (colours etc.) the user's expectations are guided by the combination of short legends on the leftmost, and (on gtk2) the depressed outline. Those visual hints aren't nearly as strong on the "busier" debugger backend page, where the leftmost legend is much longer... I'm not sure if that really is an issue, or if it's entirely down to everybody pretty much having to use the debugger page and hardly anybody fiddling with colours.

Similar apologies to OP for waylaying the thread, but if the choice of debugger is significant in the problem I think it's justified.

MarkMLl
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 26, 2024, 04:23:44 am
Sorry on getting off topic...
How is a debugger and debugger-related dialogue off-topic? 'I' do not think anything said was off-topic as 'I learn with each post when someone says or shares something. All good at my end :)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 26, 2024, 04:28:40 am
Similar apologies to OP for waylaying the thread, but if the choice of debugger is significant in the problem I think it's justified.
If 'you' or anyone apologizes again for sharing what to 'me' is very useful information you leave me no choice but to say for $DIETY's sake Mark  8-)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 26, 2024, 02:42:08 pm
Hello @MarkMLl and @Martin_fr,

I tested what you both said and the first screenshot shows the warning in red and I have a question about the second screenshot what are all of those? I have never seen a LLDB Debugger (Alpha) before??
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 26, 2024, 03:08:23 pm
https://wiki.freepascal.org/Debugger_Status

LLDB like GDB is a command line debugger, that you can download. It supports Linux, Win and Mac.

In the IDE it was added as "LLDB with FpDebug" for Mac, since the pure "FpDebug" does not work for Mac.

"LLDB (Alpha)" without FpDebug was just a by product. It exists, but has no support. (hence Alpha).

FpDebug only supports the Intel/Amd architecture, so for other targets other debuggers are needed. And also for cross debugging and embedded other debuggers are needed. (though there is an FpDebug based debugger for some avr embedded...)


On Windows, gdb is still shipped with the IDE => so that can be used. However it delivers a significantly lesser experience. There are a very few edge cases where it still may be useful. (like in some scenarios, when debugging inside the windows kernel, it gives longer stack traces // or cross debugging from a 32bit IDE to a 64bit project -> really should use the 64bit IDE instead)
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: PascalDragon on October 26, 2024, 03:40:05 pm
It is in system.inc
Code: Pascal  [Select][+][-]
  1. Procedure fpc_assert(Const Msg,FName:Shortstring;LineNo:Longint;
  2.    ErrorAddr:Pointer); [Public,Alias : 'FPC_ASSERT']; compilerproc;
  3. begin
  4.   if codepointer(AssertErrorProc)<>nil then
  5.     AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
  6.   else
  7.     HandleErrorAddrFrameInd(227,get_pc_addr,get_frame);
  8. end;
  9.  

Mind that this is an intrinsic. As you can see the boolean result of the condition is not in the parameters => that code is inlined into your calling procedure. So the above is only called, if the condition fails.

Afaik it then depends. If any unit in your app (including recursively any unit you used) uses "SysUtils then it throws an exception.

And if you want you can catch that exception.

And as one might also conclude from that code: one can replace AssertErrorProc if one wants. For example the mentioned throwing of an exception is accomplished by the SysUtils unit setting AssertErrorProc in its initialization section.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 27, 2024, 02:39:20 am
https://wiki.freepascal.org/Debugger_Status
Many thanks for the link..

LLDB like GDB is a command line debugger, that you can download. It supports Linux, Win and Mac.
Ok..

In the IDE it was added as "LLDB with FpDebug" for Mac, since the pure "FpDebug" does not work for Mac.
Ah, I see now..

"LLDB (Alpha)" without FpDebug was just a by product. It exists, but has no support. (hence Alpha).
Hmm.. interesting.

FpDebug only supports the Intel/Amd architecture, so for other targets other debuggers are needed. And also for cross debugging and embedded other debuggers are needed. (though there is an FpDebug based debugger for some avr embedded...)
Thank you for taking the time to explain all this, very much appreciated.


On Windows, gdb is still shipped with the IDE => so that can be used. However it delivers a significantly lesser experience. There are a very few edge cases where it still may be useful. (like in some scenarios, when debugging inside the windows kernel, it gives longer stack traces // or cross debugging from a 32bit IDE to a 64bit project -> really should use the 64bit IDE instead)
Your joking right? 'Who' debuuged from a 32bit IDE into a 64bit project that is not going to end well as MarkMLI would say. You have to be insane to do something like that or simply did not know better?
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Martin_fr on October 27, 2024, 11:17:33 am
Your joking right? 'Who' debuuged from a 32bit IDE into a 64bit project that is not going to end well as MarkMLI would say. You have to be insane to do something like that or simply did not know better?

Over the years I have learned that some of the things I take for granted (as in "how else could you possible do that") are anything but that. And that there are other ways to it. Even if those other ways don't work for me, they still make sense.

Maybe someone has some IDE add on, that only comes for 32bit (e.g. requires a dll that only exists in 32bit)? That can happen if you write software to control external legacy hardware (and you need it to work in the designer too), and the drivers are 32bit. If that is industrial, then new hardware may cost 5 or 6 digits figures.
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 27, 2024, 11:21:33 am
It is in system.inc
Code: Pascal  [Select][+][-]
  1. Procedure fpc_assert(Const Msg,FName:Shortstring;LineNo:Longint;
  2.    ErrorAddr:Pointer); [Public,Alias : 'FPC_ASSERT']; compilerproc;
  3. begin
  4.   if codepointer(AssertErrorProc)<>nil then
  5.     AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
  6.   else
  7.     HandleErrorAddrFrameInd(227,get_pc_addr,get_frame);
  8. end;
  9.  

Mind that this is an intrinsic. As you can see the boolean result of the condition is not in the parameters => that code is inlined into your calling procedure. So the above is only called, if the condition fails.

Afaik it then depends. If any unit in your app (including recursively any unit you used) uses "SysUtils then it throws an exception.

And if you want you can catch that exception.

And as one might also conclude from that code: one can replace AssertErrorProc if one wants. For example the mentioned throwing of an exception is accomplished by the SysUtils unit setting AssertErrorProc in its initialization section.

Hi @PascalDragon. I am yet very new to all this and trying to teach myself how things work under the hood. So, The fpc_assert procedure checks whether a custom error handler (AssertErrorProc) is set? If it is, it uses it to handle the assertion. Otherwise, it uses a default handler (HandleErrorAddrFrameInd) ? Is that the way things work?

I also ran the code snippet above throughchatGPT as it has many times helped me to break down things and understand how the code works. This is what chatGPT said when I asked it to give me a heavily commented breakdown and explanation:

---
Code: Pascal  [Select][+][-]
  1. Procedure fpc_assert(Const Msg, FName: Shortstring; LineNo: Longint; ErrorAddr: Pointer);
  2.   // Declares the procedure 'fpc_assert', which is used to handle assertion errors.
  3.   // Parameters:
  4.   //   - Msg: A message string that provides details about the assertion error.
  5.   //   - FName: The name of the file in which the assertion failed.
  6.   //   - LineNo: The line number in the file where the assertion failure occurred.
  7.   //   - ErrorAddr: A pointer to the address where the error occurred, which can
  8.   //     help in debugging the issue by showing the memory location.
  9.  
  10.   [Public, Alias : 'FPC_ASSERT'];  // The procedure is public and has an alias 'FPC_ASSERT'.
  11.                                    // This means it can be called using 'FPC_ASSERT' as an alternative name.
  12.   compilerproc;  // This attribute specifies that it is a compiler-provided procedure
  13.                  // and can only be used internally by the compiler.
  14.  
  15. begin
  16.   if codepointer(AssertErrorProc) <> nil then
  17.     // Check if 'AssertErrorProc' (a custom assertion error handler) is set.
  18.     // 'codepointer' is used to obtain the code pointer of 'AssertErrorProc' and check if it's not nil.
  19.     // If it's nil, no custom error handler is defined, so we use a default handler instead.
  20.  
  21.     AssertErrorProc(Msg, FName, LineNo, ErrorAddr)
  22.     // If 'AssertErrorProc' is not nil, call it with the provided assertion details (Msg, FName, LineNo, ErrorAddr).
  23.     // This allows the custom handler to process the assertion failure as needed.
  24.  
  25.   else
  26.     HandleErrorAddrFrameInd(227, get_pc_addr, get_frame);
  27.     // If 'AssertErrorProc' is nil, use the default error handler 'HandleErrorAddrFrameInd'.
  28.     // Parameters for 'HandleErrorAddrFrameInd':
  29.     //   - 227: Likely a specific error code indicating an assertion failure.
  30.     //   - get_pc_addr: Function to get the program counter (PC) address where the error occurred.
  31.     //   - get_frame: Function to get the current stack frame, which helps in tracing the error context.
  32. end;

It also gave me this:
Code: Text  [Select][+][-]
  1. Key Points Explained
  2.  
  3.     Parameters:
  4.         Msg: A short string with the error message for the assertion. This message usually describes what the assertion expected to be true.
  5.         FName: The file name where the assertion failed, which aids in debugging by showing the source location.
  6.         LineNo: The line number in the file where the failure happened, which helps pinpoint the exact location in the source code.
  7.         ErrorAddr: The memory address where the error occurred, useful for lower-level debugging.
  8.  
  9.     Error Handling Logic:
  10.         Custom Handler (AssertErrorProc):
  11.             AssertErrorProc is checked first. If it’s not nil, it means a custom error-handling procedure is set, and it will be used to handle the assertion.
  12.            This is useful if developers want to customize how assertions are reported or handled.
  13.         Default Handler (HandleErrorAddrFrameInd):
  14.             If AssertErrorProc is nil (no custom handler is provided), it falls back on a default handler, HandleErrorAddrFrameInd. This function uses
  15.             hardcoded values and system functions (get_pc_addr and get_frame) to identify the program counter and stack frame, aiding in debugging
  16.            by showing the context of the assertion failure.
  17.  
  18. This setup allows the fpc_assert procedure to either use custom handling or revert to a default approach, ensuring assertions are managed consistently,
  19. even if a custom handler is absent.

Is the above correct? The reason I ask is when I run anything through chatGPT I usually get myself in a lot of trouble with the community or end up being told not to use generated AI nonsense. But to me, chatGPT is simply another 'tool' that has helped me understand code which at first was way over my head. I decided to share this in the hope if the breakdown is correct and accurate it can help others who are newbies like myself.

 
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Joanna on October 27, 2024, 12:14:47 pm
Quote
Is the above correct?
You could ask chat gpt  :D
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 27, 2024, 01:07:04 pm
Quote
Is the above correct?
You could ask chat gpt  :D
I did ask and chatGPT said please go ask the gods. So I did :)
PascalDragon = One of the Pascal Gods!
Soo.. HA!  :P
Title: Re: How to Debug and Step into Assert() Function in Lazarus?
Post by: Aruna on October 27, 2024, 01:13:30 pm
Over the years I have learned that some of the things I take for granted (as in "how else could you possible do that") are anything but that. And that there are other ways to it. Even if those other ways don't work for me, they still make sense.
True... been there, done that :) recently with a Arduino Nano and getting Laz-IDE to talk to it ( bi-directional) and MarkMLI freaked out and wanted to know "why are you using file operations on a serial comm port"  and he was right to ask but I could not for the life of me get Synapse to be my friend or suss out how Synapse wants things done so I went old school and the thing is my file operations worked!

Maybe someone has some IDE add on, that only comes for 32bit (e.g. requires a dll that only exists in 32bit)? That can happen if you write software to control external legacy hardware (and you need it to work in the designer too), and the drivers are 32bit. If that is industrial, then new hardware may cost 5 or 6 digits figures.
Oh yes that... I totally forgot the rather pricey industrial aspect!
TinyPortal © 2005-2018