Forum > Debugger

debugger false breakpoint

(1/4) > >>

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  [+][-]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";}};} ---procedure P1;begin...x:=x+1;  <- here put and remove the breakpoint to see the difference..end; Procedure P2;begin..(*P1;*)end; 
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:

--- Quote from: Paolo on December 17, 2021, 06:53:35 pm ---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.

--- End quote ---

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....

Navigation

[0] Message Index

[#] Next page

Go to full version