fpdebug and BackTraceStrFunc show wrong line number on exception

[RolfW]

Look at the attached example program and screenshorts.
In short:
procedure Test2 raises an exception in line 46.

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

1. procedure Test2;
2. begin
3.   ;
4.  
5.   raise Exception.Create('Test');
6. end;
7.  

The fpdebug notification shows an exception in line 43. Same result as BackTraceStrFunc. fpdebug jumps to line 43 ("begin") if I "Break" the program exceution. gdb works ok.
Tested with Lazarus 3.99 20023-10-08 x86_64_win64-win32/win64.
I assume that this is a fpc issue but you may want to have a look at it before publishing a new release.
Thank you, Rolf

[Martin_fr]

Interesting....

The stack window shows the correct line.

The assembler to (in a way)... That is the assembler depends on what the convention is. Currently that is to show the return address, which is one after the call statement (and in this case on the next line).
Actually it shows both... The green arrow, at line 46 (which should be selected in the source editor). And the selected line after the call.
And that has (at least partially) technical reasons: The callstack only has the return address, after the "call". Intel can't be disassembled in reverse direction (var len asm stmt). Of course in this case the start of the procedure is known, so we get the asm above the return point. But if there is no known start point, then it can't be done. So for the selection, it is "after the call". Since in this case, the line is known from the editor, it is shown (green arrow).

And that is interesting, because it is correctly 46.

Which mean there are 2 issues.
1) The editor is wrong (bug in the IDE)
2) The asm should be in sync with the editor, but it does not copy the error. (which, yes, it should) (also bug in the IDE)

The problem in the Editor is likely in the "cache for line numbers". I.e. the IDE stores where the line number was when you started the debugger => so if you edit while debugging, and lines move, the IDE can still map them to what the debugger gets from the debug info. That mapping is not always exact (but only once the source was edited, because new lines have no info, joined lines can only keep one info, .... )

[Martin_fr]

And it turned out to be some place else....

[RolfW]

A hint: ExecptAddr seems to be ok. I picked up the ExceptAddr shown in BackTraceStrFunc and defined a fpdebug break for this address. The result is as expected: A break in line 46 before the  raise ... statement was executed.

[Martin_fr]

I fixed it in the meantime.

[RolfW]

I fixed it in the meantime.

Where can I find the fix? Is it in the main or in the 3.2.2 fixed branch?
Thank you, Rolf

[Martin_fr]

It is fixed in fpdebug. So it is in the Lazarus git

In fixes-3-0:
e49d174f1732cffe49f726ceb8c4c7a724e80dff
* LazDebuggerFp: Fixed line number for exceptions.

in main:
bacefb51aeba1be609d807ae38164acfff461b60

[Martin_fr]

And I just found why it was broken in first....

It is now broken when using "raise at"

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

1.   Raise Exception.Create('foo') at get_caller_addr(get_frame), get_caller_frame(get_frame);

For example if you have debug info for the RTL, and get a TStringList bounds error.

-- EDIT: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40544

[RolfW]

It is fixed in fpdebug. So it is in the Lazarus git

In fixes-3-0:
e49d174f1732cffe49f726ceb8c4c7a724e80dff
* LazDebuggerFp: Fixed line number for exceptions.

in main:
bacefb51aeba1be609d807ae38164acfff461b60

Does this fix BackTraceStrFunc too?
Rolf

[Martin_fr]

Does this fix BackTraceStrFunc too?

Sorry, I missed that. No that is not changed. (needs someone from the fpc team to look at)

[RolfW]

Sorry, I missed that. No that is not changed. (needs someone from the fpc team to look at)

Shall I open an issue for BackTraceStrFunc?
Rolf

[Martin_fr]

I don't know what is indented there. But probably.

Also make sure to indicate the debug info you use (most likely Dwarf) (though afaik on Win 32 bit you can still do stabs)

And probably your OS too.

Note that very likely you will get unexpected resolves. Either for "raise" or "raise at"
But that is not due to the BackTraceStrFunc

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

1.   raise Exception.create('abc') at get_caller_addr(get_frame), get_caller_frame(get_frame);

The "at" returns the address of the asm instruction after the "call" (and often that is in the next Pascal code line).

And, if the BackTraceStrFunc  is fixed, then on any stack dump, for any caller it will report (in some/many cases, but not always) the next line.
(well that then may depend on OS, CPU and debug info...)

So I don't know if the "bug" is intentional.

Currently the BackTraceStrFunc  returns (at least in some cases / not verified) the line before (or is it the line of the address before / which is different, but which may be wanted)

This "bug" solves the "address after call instruction" issue.
Technically it resolves it in the wrong place (if it is meant as a resolve, which I do not know). Because BackTraceStrFunc  does not know if the address it deals with, comes from a stacktrace, or other place. 

Note that this may not apply to all CPU architectures. And OS and debug info type can have an impact, but not sure if they do.

[RolfW]

I don't know what is indented there. But probably.

GetLineInfo reports wrong func/ line values:
https://gitlab.com/freepascal.org/fpc/source/-/issues/40471
Rolf