debugger false breakpoint

[Paolo]

Hello,

here what I see:

I have a piece of code with a procedure commented and a breakpoint placed inside such procedure, something like this:

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

1. procedure P1;
2. begin
3. ...
4. x:=x+1;  <- here put and remove the breakpoint to see the difference
5. ..
6. end;
7.  
8. Procedure P2;
9. begin
10. ..
11. (*
12. P1;
13. *)
14. end;
15.  

what I see is debug SIGSEGV error. Once the breakpoint inside of the commented routine is removed all it is fine again. I seems that the debugger starts to be confused, in fact I noticed that the SISSEGV happens on the subsequent routine, but If I simply change position (swap) the order of subsequent routines the problem disappears.
I have tried to reproduce such behavior in small piece of code, I wasn’t be able to reproduce it, but I observed here something strange again. In the attached code, if there is a breakpoint on row 37 when I run the code, it stops at the begin word of click event as if there is a breakpoint, if I remove the breakpoint all becomes fine again.

PS: the code is completely useless, just for test.

window 10 pro, laz 2.0.12 fpc 3.2.0

[Martin_fr]

I couldn't get the sigsegv with 2.2RC or 2.3. (using gdb for testing). Haven't got a 2.0.12 installed right now.
Do you have the exact message? Is it an "ouch the debugger..."?

Any info in menu: view > debug windows > debug output

I think in 2.0.12 "debug output" is still in "debug windows", otherwise it is in "ide internals" (view menu)

As for the "stop at next begin".
With gdb that is normal.

The procedure above is basically dead code, and for such procedures fpc does not create correct debug info.
Line info is supposed to have the address of the line, and well if the code is not in the exe, then that is not possible.

FPC 3.2.3 creates line info with address like $000000, $00000C, $0000011 .....
The versions of gdb I tested just ignore this, and pretend there is no code at this line.

However, if I tell gdb to set a breakpoint at any line that has no code, gdb will gladly find the next line (even if that is hundreds of line down) and set the breakpoint.
In your case at the "begin".

Btw, it stops twice at "begin", because fpc pretends some of the code in the "end" would be in the "begin" line. (and that hits the breakpoint / the line has more than one location, each location will stop => required and correct if it is a generic that has several specializations).

[Paolo]

the sample code doesn't reproduces the error, just the stop at next routine "begin"

in my code I have: "external : SIGSEGV"

nothing in : debug -> debug windows -> events Log

In tha attached test case I see something similar at what you say, in my code the debug stops at the "end;" of next routine.

[Paolo]

if I debug in "debug" mode, no SIGSEGV.

[Martin_fr]

the sample code doesn't reproduces the error, just the stop at next routine "begin"

in my code I have: "external : SIGSEGV"

nothing in : debug -> debug windows -> events Log

In tha attached test case I see something similar at what you say, in my code the debug stops at the "end;" of next routine.

Not the "event log", the "debug output" => that is full with commands send to gdb, and gdb's responses.

Ok, so the debugger tells you that your app had the "external : SIGSEGV"?
It is neither the IDE, nor gdb that crashed?

In that case it would be needed to reproduce it.
Or I can get you a series of steps to take and find more about the issue.

It could be a problem in gdb. But it could also be in FPC.

What optimization level to you compile with? -O- or -O1 ?

Try -O- (lvl 0 / no opt)
Or try compiling with -OoNOPEEPHOLE
and see if the crash still happens.

Even if that fixes your issue, there may be an issue in fpc that then should also be fixed.
Watch the "debug output" while setting the breakpoint. In the gdb response should be an address. Note down that address (the entire message).

Step (if need without the breakpoint) to the first line of the function, and open it in the disassembler.
Is the address you found earlier, the start of any of the statements listed by the disassembler?

Keep the exact exe file that you used. There may be a need to get a dump of debug info....

[Paolo]

What optimization level to you compile with? -O- or -O1 ?

same problem both -O and -O1

view > debug windows > debug output

I found it in view > IDE internals > debug output

this is a piece of debug output vindow content (I clear the list just before the crash)
it sarts with

&"Cannot access memory at address 0x13c31926f8\n"

and ends with (it is the the subsequent procedure)

(gdb)
<-stack-list-arguments 1 0 0>
^done,stack-args=[frame={level="0",args=[{name="AAB",value="0x5ed9980"},{name="AXY",value="<error reading variable: Cannot access memory at address 0x13c31926f8>"}]}]
(gdb)
<-stack-list-locals 1>
^done,locals=[{name="N",value="1"}]
(gdb)

*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning=

[Paolo]

nothing change alo with option -OoNOPEEPHOLE (I put it in the project options -> compilation and link -> linking, right ?)

[Paolo]

Even if that fixes your issue, there may be an issue in fpc that then should also be fixed.
Watch the "debug output" while setting the breakpoint. In the gdb response should be an address. Note down that address (the entire message).

done, it places the breakpoint at the wrong place, ie the next procedure, even if in the IDE I see it at the right place!

[Paolo]

in the view breakpoint window the line number is right.

If I look at the debug output, the content is the same for both if I put the breakpoint in the next routine and if I put the breakpoint in the commented procedure, so the breakpoint seems OK, but in the first case it works in the second crash.

[Paolo]

now it works if I do:

- go to project options -> tick verify call to method (-CR)

now the break point is fully ignored.

I do not if it happens by accident or such settings plays a role in this situation

[Martin_fr]

ok, there are 2 issues: "stop at begin" and "access violation"

The "stop at begin" is "by design".
That is from all I know, gdb behaves like this by intention.

I am not sure, how much (if at all), the IDE is currently aware of this. And if/what could be added to improve this.
Currently unfortunately this does not make my todo list, as there are to many other items of higher priority.

There may be an issue report for it already, if not it can be created....
Mind that to a degree it is considered useful, if the breakpoint is just one or two lines above.


"access violation"

You may have to open the "debug output" before starting the debugger. Otherwise not all info is captured.
Or you can unset, and again set the breakpoint while the window is open.

Looking for lines like this:

Code: Text  [Select][+][-]

1. <info line "B:\tmp\dbg\unit1.pas":46>
2. &"info line \"B:\\tmp\\dbg\\unit1.pas\":46\n"
3. ~"Line 46 of \"unit1.pas\" starts at address 0x10003a629 <$fin$00000139+9> and ends at 0x10003a63a <DEBUGSTART_$UNIT1+26>.\n"
4. ^done
5. (gdb)
6. <-break-insert  "\"B:/tmp/dbg/unit1.pas\":46">
7. ^done,bkpt={number="8",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0",original-location="B:/tmp/dbg/unit1.pas:46",locations=[{number="8.1",enabled="y",addr="0x000000010003a629",func="$fin$00000139",file="unit1.pas",fullname="B:\\tmp\\dbg\\unit1.pas",line="46",thread-groups=["i1"]},{number="8.2",enabled="y",addr="0x000000010003a654",func="Button1Click",file="unit1.pas",fullname="B:\\tmp\\dbg\\unit1.pas",line="46",thread-groups=["i1"]}]}
8. (gdb)
9. <-break-enable 8>
10. ^done
11.  

There are 2 addresses for this line

addr="0x000000010003a629" that is inside the hidden finally block that fpc generated for the procedure.
addr="0x000000010003a654" the "begin" line.

=> But the question is this: Are both address actually at the start of an assembler instruction?

< Background >
Assembler instruction can be multiple bytes. Breakpoints, replace the instruction with "int 3", that will be caught by the debugger.
If the address is in the middle of an assembler instruction, then instead of a breakpoint, its a random code modification, and that would likely crash.
< /Background >

If it is in the middle, then the question is: Did FPC write a wrong address in the debug info? Or did GDB get something wrong.
- If its fpc, then it needs to be fixed there.
- If its gdb, well you can try to report it to them, but you would need some way for them to reproduce it. (and check against the latest gdb first). I currently do not have the time, to prepare a gdb report....

So once you have the address, you need to step (potentially assembler-single step-into) each of those functions, and show the disassembler for them.
Or you may be able to disassemble with objdump.

Then you can look for the address, and see if it is at the start of a statement or not.

objdump (lineinfo) can also show you, what addresses fpc actually included.

[Martin_fr]

now it works if I do:

- go to project options -> tick verify call to method (-CR)

now the break point is fully ignored.

I do not if it happens by accident or such settings plays a role in this situation

That is more or less "got lucky" workaround.

It's a solution for you. But it does not help finding the original cause of the access-violation, and determine if there is a bug in fpc.

[Paolo]

Dear Martin,

here attached the debug output, it is collected in a doc file in two colums.

The first one is when there is the crash and the second no crash.

the first is obtained as follow:

- put the breakpoint on line 2500 (in the commented procedure)
- clear the debug output
- then run
- do the "click" that causes the crash
- copy paste the debug result on the first column

the second is obtained

- put the breakpoint on the line 2524 (line where in the first case the debbuger jump before crash)
- clear the debug output
- then run
- do the click (no crash)
- copy paste the debug result on the second column

in yellow the most evident differences I can see (I tried to keep the two column aligned by row for easy comparisons), I remove also some rows very long and apperently identical

[Martin_fr]

https://gitlab.com/freepascal.org/fpc/source/-/issues/39499

[Paolo]

Thanks Martin for the support, as soon as possible I want try Fpdebug and see what is happening.