F8 step-over sometimes goes into assembly code lazarus / 12-Debugger ---------------------------------------------------------------------- ad1mt · 2024-03-19 11:13 F8 step-over sometimes goes into assembly code. I'm puzzled about this... can anyone explain why this sometimes happens. Thanks. ---------------------------------------------------------------------- Martin_fr · 2024-03-19 11:44 There is a lot of info missing... Lazarus version? (2.x / 3.0 / 3.99) Fpc version? OS? 32/64Bit?  (All the same for OS, Lazarus, and project? or cross compile?) Debugger Backend (FpDebug, Gdb, Llld+FpDebug) Did you compile With optimization OFF or Level-1? If not FPDebug, and if 32 bit: Stabs or Dwarf? Any indication on where the show assembler code is, in relation to the code that you were stepping? E.g. What does the "Callstack" window show? Is your code in the list (Where)? Does the asm window show any names in-between/ above the asm statements (anywhere but NOT in the comments)? ---------------------------------------------------------------------- ad1mt · 2024-03-19 15:49 I hoped this might be an easy question to answer, but I can see its not. It does not bother me enough to spend time investigating/reporting. ---------------------------------------------------------------------- Martin_fr · 2024-03-19 16:41 Well, it's a bug. And one that I am not aware off. So in order to fix it (or even just guess what it may be), I need some starting point. ---------------------------------------------------------------------- Edson · 2024-03-23 18:26 I have the same problem in Windows 10. It happens in some cases, like when I do F8 in an instruction that have a string comparison. I work at level 1 for optimization and Dwarf with sets. ---------------------------------------------------------------------- Eugene Loza · 2024-03-23 18:50 Oh, so it can actually be a bug? I always thought it's intended behavior (when a line of code simply cannot be displayed for some reason). Always ignored the feature, but some units like include flies (seh64.inc) or dotted unitnames (generics.collections.pas) sometimes fail to resolve properly, especially during an exception. So I should be on lookout for those... ---------------------------------------------------------------------- Martin_fr · 2024-03-23 18:53 Quote from: Edson on March 23, 2024, 07:26:41 pmI have the same problem in Windows 10. It happens in some cases, like when I do F8 in an instruction that have a string comparison. I work at level 1 for optimization and Dwarf with sets. Your assembler Window tells me you are using gdb as backend. And indeed, with GDB this does happen. (I am not sure if it is a gdb issue, or something to do with the way fpc wrote the debug info.) However, it works fine (at least for all my testing) with FpDebug. I would highly recommend to switch to FpDebug. Tools > Options > Debugger > Backend. Most likely the toolbar on top of the page already has an entry FpDebug that can be selected (If not click "Add", and select in the dropdown in the middle of the page). ---------------------------------------------------------------------- Martin_fr · 2024-03-23 19:18 Quote from: Eugene Loza on March 23, 2024, 07:50:57 pmOh, so it can actually be a bug? I always thought it's intended behavior (when a line of code simply cannot be displayed for some reason). Always ignored the feature, but some units like include flies (seh64.inc) or dotted unitnames (generics.collections.pas) sometimes fail to resolve properly, especially during an exception. So I should be on lookout for those... That is a misunderstanding. F8 should step to the next line of Pascal code.  So the next line should be known, and should be reached. (That is, unless it is at the "end;" of a function, and leaving the function, and the caller has no debug info, then there would be no source to show) So the bug here is that F8 does not  step to the next line as expected. The bug is that F8 stops somewhere else. => Then the asm Window opens. (And while there are cases, where the asm window opens incorrectly, in this case - if one ignores that the F8 failed - it would be correct). After all, if it is  "F8 step over" in GDB going wrong, then gdb tells the IDE that your step ended at this asm statement. In other words gdb tells the IDE you wanted to purposely step to this asm statement for which no source is known. Once the IDE believes that was what you wanted, then it is correct to show the asm window.  Of course with F8 this can only happen due to the prior bug in F8. About the asm Window in other cases. When an exception happens and the app gets paused, then the actual "raise" in the RTL may not have debug info. Maybe not even the caller (like TStringList in classes). But some code with debug info should have called the code that caused the exception, and ideally the debugger should find it and go there. That does sometimes fail. That is a bug.  I have to check, I recall having done some work on it to improve it (but not sure how well the result was  / And also how it affect gdb/lldb as it was likely tested for fpdebug). There may be other similar cases. Anyway, whatever the cause is. And whatever the config (gdb, fpdebug, lldb) it is always good to mention it. Even if in some case (like gdb) the chances are slim that anything can be done.... There are still - after excluding 3rd party like gdb - enough cases that simply aren't fixed because I don't know they exist. The debugger can be run in so many different setups, that it is impossible to go through all of them myself. E.g. For my development I often need an RTL with debug info. But that changes fundamentally how many things are handled in the debugger. So I don't always get the out of the box experience. ---------------------------------------------------------------------- Eugene Loza · 2024-03-23 19:29 Thank you! "Tools > Options > Debugger > Backend" Tells me that I'm using FpDebug. I'll then just pay more attention to such cases and will be able to ask more specific questions ---------------------------------------------------------------------- Eugene Loza · 2024-03-23 19:38 E.g. remembered a bug I've had a very hard time tracking two weeks ago: 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 program Project1;uses  Generics.Collections, Generics.Defaults; var  Dict: specialize TObjectDictionary;begin  Dict := specialize TObjectDictionary.Create([doOwnsValues]);  Dict.Add('a', TObject.Create);  Dict.Add('a', TObject.Create);end. Second "Add" crashes because the key already exists, but it tries to look for "Generics.Dictionaries" in the project folder not in FPC sources. And "resurfaces" from the assembler window only inside of "try..except" it was wrapped in. Note, I'm using FPCUpDeluxe to install FPC+Lazarus so hypothetically it can affect the paths. ---------------------------------------------------------------------- Martin_fr · 2024-03-23 22:07 Quote from: Eugene Loza on March 23, 2024, 08:38:46 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1;uses  Generics.Collections, Generics.Defaults; var  Dict: specialize TObjectDictionary;begin  Dict := specialize TObjectDictionary.Create([doOwnsValues]);  Dict.Add('a', TObject.Create);  Dict.Add('a', TObject.Create);end. Second "Add" crashes because the key already exists, but it tries to look for "Generics.Dictionaries" in the project folder not in FPC sources. And "resurfaces" from the assembler window only inside of "try..except" it was wrapped in. Please report this. (It happens with 3.2 and 3.99 I can't currently exactly tell where it goes wrong. Probably will need a team effort (that is me and "have to find who"). The debugger gets filenames (sometimes with a simple include folder, relative to a package main dir). The debugger then calls the packager in the IDE (I think at least its the packager), and that resolves pathes. I can't tell why it does not work for this one.... - On a first glance, I haven't spotted any funny business due to it being a specialization (there had been issues with fpc writing incorrect debug info / but *seems* ok here( - Maybe the dotted name. I have seen work on that for the IDE. But not sure where that stands now. Unfortunately for you, it's not going to make it into my top-priority list. So may take a while. Fortunately for you there is a workaround.   Tools > Options > Debugger > General There is an edit "Additional Search path" Put the path to the file into that. E.g.:    C:\fpc\source\packages\rtl-generics\src\inc\ If you report it, copy the following (thanks): "There may be an issue that the debuggers additional search path must include the '/inc', because that is also given in the dwarf info" ---------------------------------------------------------------------- Martin_fr · 2024-03-23 22:19 Also it is an interesting question, if failing to find a source file should - go further out on the stack to find a caller with a source that can be located - show the asm. In either case, the question only arises due to a prior fault. (in this case bug, but could be a user that deleted a file). As such, this is how do deal with a follow up problem. And, if the IDE tried to avoid the asm window in that case, it could encounter 10 further different missing files, asking for each of them. That would hardly be better than the asm window, and then the option to search on the stack. The other option would be: Not to ask at all. Ignore that the compiler said the file should exist. Treat - compiler did not include debug info - file is not on disk as identical. Then the stack could be searched. Downside, you don't have the option any more to locate the file, and see the code in the file. (I have encountered that / though really long ago, when this error was far more common / and searched for the file and opened it -- so the option to do so is more than theoretical) Could be a global option. But given that (when the current bug is solved) this should rarely happen, not on the "near future" list. ---------------------------------------------------------------------- Eugene Loza · 2024-03-24 08:30 QuoteUnfortunately for youOh, that's perfectly ok I lived with this kind of issues since around 2009 and didn't even know it's something that is not supposed to happen and should be reported Started filing the report but then figured out I'm not sure if I should report it to FPC or to Lazarus issue tracker? Sounds like FpDebug is not strictly part of Lazarus, but the issue manifests for me in Lazarus and I don't even know how to use a debugger in pure FPC. ---------------------------------------------------------------------- Martin_fr · 2024-03-24 12:16 Quote from: Eugene Loza on March 24, 2024, 09:30:12 amQuoteUnfortunately for youOh, that's perfectly ok I lived with this kind of issues since around 2009 and didn't even know it's something that is not supposed to happen and should be reported Started filing the report but then figured out I'm not sure if I should report it to FPC or to Lazarus issue tracker? Sounds like FpDebug is not strictly part of Lazarus, but the issue manifests for me in Lazarus and I don't even know how to use a debugger in pure FPC. In this case Lazarus. FpDebug is Lazarus. And yes, it reads input by FPC, which could in some other cases be buggy. But then, if that is the case, I can still move it. (In the case "generic.collection" not found, it isn't) ---------------------------------------------------------------------- Martin_fr · 2024-03-24 17:35 Quote from: Eugene Loza on March 23, 2024, 08:38:46 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1;uses  Generics.Collections, Generics.Defaults; https://gitlab .com/freepascal.org/lazarus/lazarus/-/issues/40862 ---------------------------------------------------------------------- Eugene Loza · 2024-03-24 17:42 Sorry for the delay with this - was going to get back to the issue in a couple of hours... And huge thank you! ---------------------------------------------------------------------- Eugene Loza · 2024-06-17 16:16 One more potential issue (unless it's a special case of the previous one): 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 program Project1;uses  Classes, SysUtils;begin  try    WriteLn(TObject(nil).ClassName);  except  end;end. 1. Run the program 2. Get Access Violation 3. Press F8 4. The file "Seh64.inc" was not found (attachment 1) 5. No. 6. Assembler window pops up (attachment 2) ---------------------------------------------------------------------- Thaddy · 2024-06-18 08:36 Are you "eating" exceptions? e.g.: do you 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 try  something that can cause an exceptionexcept // with no code until end; empty block.end;//without handling it properly?Then you get what you showed. SEH becomes useless then. Beginners mistake. It is very hard to debug such code and it is wrong, very wrong. ---------------------------------------------------------------------- Eugene Loza · 2024-06-18 08:46 QuoteAre you "eating" exceptions?No, I'm making the most minimal reproduction of the issue that is nagging me in a big project, where the exceptions are (hopefully) properly treated, though F8 "resurfaces" only in "try..except" statement, going through not very useful Assembly before that and often very little information on what exactly went wrong - only a consequence in form of an exception. Often "Call Stack" helps to debug those. But the example above shows only one thing (as the caption of this topic) : Pressing F8 goes into Assembly window instead of showing something meaningful. Adding WriteLn('Exception!') in the except block doesn't seem to change the issue. The Seh64.inc is still not found and Assembly window is displayed instead but it's one more line of code ---------------------------------------------------------------------- Thaddy · 2024-06-18 08:48 If you are sure, use the call-stack to debug it. It will narrow down to where the exception occurs. ---------------------------------------------------------------------- Martin_fr · 2024-06-20 14:25 The seh file not found may or may not be the same. Needs to be re- tested when that is fixed. But the debugger also doesn't find the exception block in this case.  That causes stepping to fail, because there isn't a next line (the CPU is in the exception throwing code...) https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40993 Afraid, that may be a while until it gets attention. ---------------------------------------------------------------------- Thaddy · 2024-06-20 15:59 A writeln in the except block is not enough. Needs sysutils to have fully functional SEH it seems. ---------------------------------------------------------------------- Martin_fr · 2024-06-20 16:04 Quote from: Thaddy on June 20, 2024, 05:59:43 pmA writeln in the except block is not enough. Needs sysutils to have fully functional SEH. You are referring to this post?Quote from: Eugene Loza on June 17, 2024, 06:16:49 pmOne more potential issue (unless it's a special case of the previous one): 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 program Project1;uses  Classes, SysUtils;begin  try    WriteLn(TObject(nil).ClassName);  except  end;end. And the copy of the code that is shown on https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40993 ? Because, to me it looks like it does have it? ---------------------------------------------------------------------- Eugene Loza · 2024-06-20 16:41 Quote from: Martin_fr on June 20, 2024, 04:25:29 pmAfraid, that may be a while until it gets attention.Thank you! No rush with this one, just a small inconvenience. Eventually I've learned to use StackTrace and sometimes can even quickly figure out where it could go wrong