Debugger ignoring assertions

[EganSolo]

Laz 3.0, FPC: 3.2.2 win64 on win 11. Assertions are being ignored with both Gdb and fpDebug.
Running in Debug Mode with
   Checks and assertion:  all checked.
   Run uses the debugger is on
   Generate info for the debugger checked
   Debugger info: Dwarf 3 (beta)
   Generate code for valgrind: not checked
   Use external debug symbols file: checked
   Use Heaptrc: checked
   Trash variables: checked
   Generate code for gprof: not checked
   Strip symbols: not checked

Assertions to check if a pointer is nil are skipped (seemingly not compiled).
These assertions take the form:

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

1.   Assert(Assigned(P), 'P is nil');
2.  

The assertions are silently skipped and they are not raised when the pointer is nil.

What am I missing?

[Thaddy]

Can it be that there is a spurious {$C-} in your app. That will override the compiler debug settings. I can not reproduce your code.
There is an easy way to test this because assertions are local, so you can do this:

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

1. { This code will override any compiler settings regarding assertions }
2. {$PUSH}// save state
3. {$C+}// force assertions on
4. Assert(Assigned(P), 'P is nil');
5. {$POP}// restore original settings

This code will override any global settings, just for that piece of code.
Btw: I used trunk from today, i.e. 331/399 on Windows11 and dwarf3 debug settings.
But that should not matter: it always worked.

Let us know if it worked: if it does then it is likely that your code contains a directive that turns the assertions off. Either {$C-} or {$assertions off} or {$assertions-}

But beware of dangling pointers: in that case the assert thinks it is valid because P is not nil...
If that is the case, you have my permission to guard P temporalily with the dreaded FreeAndNil, if applicable, and remove that after you have determined the real cause.
( I am one of those that are of the opinion that FreeAndNil is evil because it can hide hard to debug real errors )

Remark: "Trash variables: checked" makes it likely a var is NOT nil.....
So turn that off. As per documentation its use is limited to special cases, usually to investigate stack corruption.

[Martin_fr]

Assertions are done in the app itself. They happen even if there is no debugger.

But anyway, have you tried the following.

1) Set  a breakpoint immediately after the assertion. And check the value of p ?

2) Explicitly set p to nil right before the assertion?

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

1. p := nil;
2. Assert(Assigned(P), 'P is nil');

[Thaddy]

1) Set it immediately *before* the assertion and check the value of P.
2) That won't help to diagnose the issue? Does it?

[Martin_fr]

1) Set it immediately *before* the assertion and check the value of P.

After.
If we don't reach then the assertion did trigger, and we don't need to check.

2) That won't help to diagnose the issue? Does it?

It will show if the assert code is inserted by the compiler.

[Martin_fr]

Assertions to check if a pointer is nil are skipped (seemingly not compiled).

Just to add some info.

There is a difference between your case above, and "the debugger does not stop at the assertion".

According to you, the app continues to run. Code after the assert is executed.
If that is so, then that also happens if you run the app outside the IDE / without debugger?

If on the other hand, your app would simply quit/exit when the assertion is reached, and you expect it to stop in the debugger: Then make sure the code does "uses SysUtils;".
This changes the assert from a "halt" to an exception. And then the debugger will tell you it happened (if it does happen).

Anyway, just as added info.

[Martin_fr]

Also make sure your code does not change the variable "AssertErrorProc".

If it does, an assert will simply call the code you specified there. And that's it.

- Check any 3rd party code for it.
- If you have FPC/RTL with debug info, then you can inspect it, or even break in system.fpc_assert

The unit "UTrace" (LCL) does change this. But calls the old value.

[Thaddy]

Well, you are the debug expert, but I still think he should test my suggestions here https://forum.lazarus.freepascal.org/index.php/topic,65988.msg503689.html#msg503689 first.

Let's pick out the obvious first, then go and look at way more advanced things like a hooked AssertErrorProc. Nobody but us does that or knows about it..

[Martin_fr]

Well, you are the debug expert, but I still think he should test my suggestions here https://forum.lazarus.freepascal.org/index.php/topic,65988.msg503689.html#msg503689 first.

Nobody said otherwise.

[EganSolo]

Thanks to all who replied with detailed explanations. That was very helpful. Thaddy, your suggestion to turn $C+ on turned out to be right on the money. As soon as I did that, the assertions were compiled and not ignored. The cause of all this is my fatigue: The unit in question belongs to a package. The assertion check box was turned off in the package but turned on in the main program. I overlooked that detail... that'll teach me to code without taking breaks.

Thank you all, and my apologies for my idiocy.

[Martin_fr]

The assertion check box was turned off in the package but turned on in the main program. I overlooked that detail...

Project Options => Additions and overrides.
https://wiki.freepascal.org/IDE_Window:_Compiler_Options#Additions_and_Overrides

[Thaddy]

Martin,
Unless I misread that entry: where is the explicit warning that the sourcecode defines overrides the global compiler option, because that is basically what caused this mishap.
You can set the options through the dialogs to whatever you want, but the sourcecode defines have precedence over any option set through the dialogs..

And no, there is no way to change that! There is no way to ignore local defines.
Which to me is a good thing and I use it all the time.