Debugger ignoring assertions lazarus / 12-Debugger ---------------------------------------------------------------------- EganSolo · 2024-01-25 02:48 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   Assert(Assigned(P), 'P is nil'); The assertions are silently skipped and they are not raised when the pointer is nil. What am I missing? ---------------------------------------------------------------------- Thaddy · 2024-01-25 07:07 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i { This code will override any compiler settings regarding assertions }{$PUSH}// save state{$C+}// force assertions onAssert(Assigned(P), 'P is nil');{$POP}// restore original settingsThis 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 · 2024-01-25 09:29 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i p := nil;Assert(Assigned(P), 'P is nil'); ---------------------------------------------------------------------- Thaddy · 2024-01-25 11:48 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 · 2024-01-25 11:55 Quote from: Thaddy on January 25, 2024, 12:48:42 pm1) 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. Quote2) That won't help to diagnose the issue? Does it? It will show if the assert code is inserted by the compiler. ---------------------------------------------------------------------- Martin_fr · 2024-01-25 12:03 Quote from: EganSolo on January 25, 2024, 03:48:50 amAssertions 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 · 2024-01-25 12:09 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 · 2024-01-25 12:47 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 · 2024-01-25 12:50 Quote from: Thaddy on January 25, 2024, 01:47:50 pmWell, you are the debug expert, but I still think he should test my suggestions here htt ps://forum.lazarus.freepascal.org/index.php/topic,65988.msg503689.html #msg503689 first. Nobody said otherwise. ---------------------------------------------------------------------- EganSolo · 2024-01-27 01:41 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 · 2024-01-27 09:43 Quote from: EganSolo on January 27, 2024, 02:41:13 am 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 · 2024-01-27 11:29 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.