Works fine for me. Could you share more details please?
It also works (I tested) if I do not use "sysutils".
The difference should be, that if you "continue" on the "Run Error", then with SysUtils you additionally get an Exception (the exception can also be caught by your
code using "try except end". The run-error does not trigger this)
Please check under Tools > Debugger > Backend: Are you using FpDebug?
If you have "inlined" code, you may want to try and disable this for the unit in question. "{$INLINE off}"
"avr sim" => you have Win10 on AVR? or you are debugging an embedded target?
If you are using avr that is maintained by Christo. So I would have to notify him.
Also your 3rd picture shows "Debugger > General".
But what is set in "Debugger > Backend" ?
No, avr_sim is not a simulator for Lazarus code using Pascal language, but a simulator for AVR assembler language files only.
The backend is set to FpDebug. Do you need a screenshot as well?Nope, no screenshot.
Now it is getting even crazier. If I set debugging to Release (and remove all range checks), I get the added error message. Unfortunately I can't find out the source code line where this access exception occurred.
No, avr_sim is not a simulator for Lazarus code using Pascal language, but a simulator for AVR assembler language files only.
I assume avr_sim refers to Gerd's AVR simulator (http://www.avr-asm-tutorial.net/avr_sim/index_en.html)? 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...)?
But, ....1) please also check in your "project options" on the page "Debugger" (below "Verschiedenes") => It should say "Use IDE default debugger".
That is correct.2) In your "project options" > "language exceptions" ("Sprach Ausnahmen") => What entries do you have listed?
Are any "run error ..." or "range check" listed?
All those entries are enabled.3) When you debug, are there "little blue dots" in the editor's gutter?
All executable code lines have such a blue dot, not the begin and end lines.4) Your code will stop at a breakpoint?
Breakpoints work correct, if I set them.5a) 64 or 32 Bit Lazarus IDE installed?
64 bit.5b) 64 or 32 Bit project (i.e. cross compiled to 32 bit)?
Compiling for 64 bit, no cross compilation.6) Do you have libraries (dll) written in Pascal? And is the failing code in such a library?
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).7) Does the debugger inform you if you run this?
type TFooExcept = class(Exception) a: byte; end; begin raise TFooExcept.Create('123');
Works correct as expected. See attached window.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.
No, the code only uses standard components. No additional packages.
brgs, gsc
Shall I publish the Lazarus source code with the current code as well as the error-producing assembler source code for the ATmega16?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.
Shall I publish the Lazarus source code with the current code as well as the error-producing assembler source code for the ATmega16?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...
I never would have expected that switching the range checks on would mask these kind of memory access errors.Well....
@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.