Forum > Debugger
Debugger doesn't display range check errors
dg4fac:
--- Quote from: ccrause on May 12, 2022, 01:09:20 pm ---
--- Quote from: dg4fac on May 12, 2022, 11:59:07 am ---No, avr_sim is not a simulator for Lazarus code using Pascal language, but a simulator for AVR assembler language files only.
--- End quote ---
I assume avr_sim refers to Gerd's AVR simulator? If so, this is indeed a regular PC type application. Since the source is available for download, can the OP please give exact steps on how to produce this specific range check error (for example open unit X, change value Y on line Z, compile, run then click on button A and observe crash...)?
--- End quote ---
That is all correct. As compared to the published Lazarus source code (version 2.5), I have made a lot of changes towards version 2.6. So I would have to pack the complete source files as they are now. Probably I will put it on the webpage as preliminary version 2.6. Would that help?
The debug error is only occurring when I start the Timer TC0 in an ATmega16 device. And the most crazy thing is: when I start the simulation for the first time the code runs normal (without range check error) and the timer TC0 runs. If the timer reaches its overflow condition, the interrupt serrvice routine switches a pin high/low that provokes an INT1 condition. If that happens, the range check error happens. And isn't correctly displayed.
If I reset the simulator (which sets all variables to their default values), the error appears already when I write the control word to the timer TC0's TCCR0. So probably I have not resetted all variables properly in my Restart procedure.
The whole mess started because I changed the port display window completely. It wasn't working correct before, so I had to improve it. And it now works correct with other AVR device types, but not with an ATmega16's INT1.
In my previous work with Lazarus it would have been easy to find the bug. E.g. when accessing arrays out of their bounds. The debugger would have detected this and would have stopped this. He would have provided information from which it has been easy to find the bug's reason. But not now any more: it dosn't stop such an error any more, and allows that such an access violation with a false address can occur.
I want my old debugger back!
Shall I publish the Lazarus source code with the current code as well as the error-producing assembler source code for the ATmega16?
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---But, ....
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---1) please also check in your "project options" on the page "Debugger" (below "Verschiedenes") => It should say "Use IDE default debugger".
--- End quote ---
That is correct.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---2) In your "project options" > "language exceptions" ("Sprach Ausnahmen") => What entries do you have listed?
Are any "run error ..." or "range check" listed?
--- End quote ---
All those entries are enabled.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---3) When you debug, are there "little blue dots" in the editor's gutter?
--- End quote ---
All executable code lines have such a blue dot, not the begin and end lines.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---4) Your code will stop at a breakpoint?
--- End quote ---
Breakpoints work correct, if I set them.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---5a) 64 or 32 Bit Lazarus IDE installed?
--- End quote ---
64 bit.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---5b) 64 or 32 Bit project (i.e. cross compiled to 32 bit)?
--- End quote ---
Compiling for 64 bit, no cross compilation.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---6) Do you have libraries (dll) written in Pascal? And is the failing code in such a library?
--- End quote ---
Nope, I don't use libraries (as far as I know. I do not know how to produce a library. And, as an assembler freak, I hate libraries: they are completely intransparent and witchy code).
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---7) Does the debugger inform you if you run this?
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---type TFooExcept = class(Exception) a: byte; end;begin raise TFooExcept.Create('123');
--- End quote ---
Works correct as expected. See attached window.
--- Quote from: Martin_fr on May 12, 2022, 01:09:43 pm ---8) Is some of your code in (a) package(s)?
If so, open the package and ensure it is also compiled with dwarf debug info.
--- End quote ---
No, the code only uses standard components. No additional packages.
brgs, gsc
--- End quote ---
Martin_fr:
OK, one more idea....
Maybe that particular "range check" is not your app at all...
But, that would be weird, because when you compile without range-check => you do get bad behaviour....
So we do know that your app does have some bug. Maybe even a range check. But maybe not the one displayed....
Ok, that sounds very confusing....
So here is the explanation:
Maybe there is a "range check" error in the IDE itself (possible triggered when your app hits its own bug).
You can test that => if it is the IDE, and if you press "Cancel" => the IDE should close.
If the error is in the IDE then of course the debugger does not show any info. (In fact it might be that part of the debugger crashed).
As for the title of the pop up window, which clearly has the name of your project "avr-sim" => What is the title of your IDE main window (the IDE menu bar window?) => because you can set that to start with the project name / though I would still expect it to end in "Lazarus" => so this does not match your error window....
I did fix an overflow error in FpDebug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/4ad24ee8371d1fa7743fe1d0eaced1e36a5b2e24
Anyway, even if in some weird way the above applies. => We know that there is an issue in your code too.
Btw, did you try, if you can catch it using the gdb debugger?
You could also run the IDE with
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---lazarus.exe --debug-log=c:\laz-log.txt --debug-enable=DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME,DBG_ERRORS
Maybe the log catches something ...
ccrause:
--- Quote from: dg4fac on May 13, 2022, 11:53:06 am ---Shall I publish the Lazarus source code with the current code as well as the error-producing assembler source code for the ATmega16?
--- End quote ---
I think just publish the latest source with the error producing example - also with steps on how to trigger the error. With this one can start testing the code and debugger. My expectation is not to spot the error in your code, but perhaps using different debugger options may help in trapping the error.
I will test this on Linux, perhaps there the bug is easier to trap with the debugger...
dg4fac:
Hi.
--- Quote from: ccrause on May 13, 2022, 02:19:34 pm ---
--- Quote from: dg4fac on May 13, 2022, 11:53:06 am ---Shall I publish the Lazarus source code with the current code as well as the error-producing assembler source code for the ATmega16?
--- End quote ---
I think just publish the latest source with the error producing example - also with steps on how to trigger the error. With this one can start testing the code and debugger. My expectation is not to spot the error in your code, but perhaps using different debugger options may help in trapping the error.
I will test this on Linux, perhaps there the bug is easier to trap with the debugger...
--- End quote ---
I finally found the bug:
1. Switching all range checks off.
2. Provoking the access error, get the line number and its content from there.
3. Corrected the bug in this line.
4. Switched all range checks on again.
The errors are now all fixed, so I can publish the code for version 2.6 in the next days (after I prepared the Linux executable). It is really improved, compared to version 2.5. And I myself am surprised that anything works now as desired and planned.
I'd like to say Thank You to all Lazarus programmers. When I started with this avr_sim software in 2016 I was expecting that this would end in a catastrophe, like my first approach in 2005 with Kylix did. Thanks to Lazarus more and more components of the final started to work. And now I am only fixing minor errors and defective appearances. Without Lazarus I would have given up in 2017.
@Martin_fr:
I never would have expected that switching the range checks on would mask these kind of memory access errors. So, in the future, in case of an error, I will have to check the software with all range checks off, additionally. Can you probably find a way to let the other error message through with the range checks switched on, too? Those provide more info in those cases.
Thank you all for your help.
brgs, gsc
Martin_fr:
--- Quote from: dg4fac on May 13, 2022, 05:14:14 pm ---I never would have expected that switching the range checks on would mask these kind of memory access errors.
--- End quote ---
Well....
Note: in the below I say "on the heap" => for locals that is "on the stack" => but the same rules apply...
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var a: array of bytes;begin setlength(a,2); // allocates 2 bytes of mem on the heap => the heap itself is bigger though, depends on OS a[50 * 1000 * 1000] := 1;
Now you write to memory 50 MB after your allocated area => most likely outside the total heap area. You get an access violation.
With range-checking, fpc compiles the above as
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var a: array of bytes;begin setlength(a,2); // allocates 2 bytes of mem on the heap => the heap itself is bigger though, depends on OS if 50 * 1000 * 1000 > length(a) then CallRangeCheckError; a[50 * 1000 * 1000] := 1;CallRangeCheckError is a runtime error or exception. It either aborts your program, or raises on exception which will go to the next "except end" (if there is).
In either case: The assignment is not executed => no access violation.
The range checking has nothing to do with the debugger. It is compiled into your exe. If you ship this, it will do range checking at your clients PC too. (there are valid reasons to do that).
--- Quote ---
@Martin_fr:
So, in the future, in case of an error, I will have to check the software with all range checks off, additionally. Can you probably find a way to let the other error message through with the range checks switched on, too? Those provide more info in those cases.
--- End quote ---
As above: the debugger does not create the range check error. It merely catches it. (internally it just sets a breakpoint an "raise" and at "run_error".).
And normally that works. I still have no idea why it does not work in your case.
You could still produce the log as I described (by putting the error back in your code). It may or may not help in identifying why it's not caught by the debugger.
Btw, take the example above:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var i: integer; a: array [0..1] Integer; b: boolean;begin b := false; i := 2; a[i] := 1; // this changes "b" // Depend on compiler setting / optimization ... So without range check => at some point later when you happen to do "if b then ..." => your app will behave unexpected. Because b is not what you wanted.
If "b" wasn't boolean, but "b: TObject" => then you changed the internal pointer of b (the reference to the object date). => "b" will not be nil, but "b" will point to a random address.
If that address is readable you get some strange values.
If that address is not readable you get the access violation when you access "b" (which may be long after the mistake had happen).
Navigation
[0] Message Index
[*] Previous page