View Issue Details

IDProjectCategoryView StatusLast Update
0036522LazarusDebuggerpublic2020-03-27 10:06
ReporterCyrax Assigned ToMartin Friebe  
Status resolvedResolutionnot fixable 
PlatformLinux x86_64OSArch 
Product Version2.1 (SVN) 
Summary0036522: [GDB backend] Inside at certain procedure, pressing F8 continues execution of the program instead of stepping to next line.
DescriptionIn our case, unit udcutils (src/udcutils.pas) seems to be the source of this bug. Especially EnableControl procedure (line 1141). I don't know if other procedures that resides inside of the unit are problematic.

When debugger goes inside of this procedure, pressing F8 does not continue stepping behaviour so it will not step out from procedure in question either. Instead it will go straight to full execution mode. And when shutting down debugging session, it seems that debugger remembers that it was in stepping mode and goes off the rail; inside of FPC trunk sources, especially exception handling routines because closing DoubleCommander causes itself to shutdown its sockets service mechanism (needed for elevation purposes, I think?) and this causes exception happen which is handled in normal way.

This bug isn't happening at inside x86_64-linux container at all.

Attached file contains debug info generated from running instance of the Lazarus trunk and during debug process of DoubleCommander project.
Additional InformationRunning Lazarus trunk and FPC trunk inside LXC Arch i386-linux container.

Excerpt from src/udcutils.pas :
procedure EnableControl(Control: TControl; Enabled: Boolean);
  Control.Enabled:= Enabled;
  if Enabled then
      Control.Color:= clDefault;
      Control.Font.Color:= clDefault;
      Control.Color:= clBtnFace;
      Control.Font.Color:= clGrayText;
TagsNo tags attached.
Fixed in Revision
WidgetsetGTK 2
Attached Files



2020-01-06 14:12

reporter (12,595 bytes)

Martin Friebe

2020-01-06 17:37

manager   ~0120236

I went through the log, and it seems the following is happening.

There are several threads running.

Thread 1 hit a breakpoint:

You are then doing a single step from there in thread 1 (At least I did not see anything that you changed to a diff thread)

While the single step is running (stepping), an exception is raised in thread 2:
EClientServerSocketError 'Could not accept a client connection on socket: 3, error 22'

Is the above possible/correct?

This indeed will cause a problem.

Exceptions are caught by a breakpoint at fpc_raiseexception.
But hitting a breakpoint (in any thread) always interrupts the current step command. GDB has no native support to continue this step.

If the exception is on the ignore list, or if you press ignore, then the IDE detects where your step would have ended, and uses breakpoints trying to run to that location.

Unfortunately this code does not handle multi threading yet. So it tries to continue thread-2 to the step-end location of thread-1. And that does not work.

If you can use Lazarus svn trunk, you can try fpdebug (package LazDebuggerFp).
It may handle this situation better. (Though not tested...)


2020-01-07 04:01

reporter   ~0120247

EClientServerSocketError exception only happens when the program is shutting itself down.

Strangely, if I add dummy variable at the end of EnableControl procedure, the debugger can do stepping normally. It seems that GDB won't find end of procedure routine (DWARF2 debug info generation error?) and so it will continue execution without doing any steppings.


2020-01-07 04:07

reporter   ~0120248

Attached lazarus debug log. This time I added dummy variable at the end of EnableControl procedure, so now stepping works.


2020-01-07 04:40



2020-01-07 04:51



2020-01-07 04:53

reporter   ~0120249

FPC trunk r43868 i386-linux.

Built with these options:
make clean all install OS_TARGET=linux CPU_TARGET=i386 OPT="-gw2 -godwarfsets -godwarfmethodclassprefix -gl -O- -Xs- -Si- -vbq -Sew- -XX- -CX- -dEXTDEBUG -vh- -vn- -vw- -dDEBUG_NODE_XML -Cit -gt -gv -Cg  -Fl/lib -Fl/usr/lib -Fl/usr/lib/gcc/i686-pc-linux-gnu/9.2.0 -dTEST_WIN32_SEH" FPC=fpc REVSTR=43868 IDE=1 NOWPOCYCLE=1 ALLOW_WARNINGS=1 LINKSMART=0 CREATESMART=0 INSTALL_PREFIX="/mnt/shares/ohjelmointi2/fpc/i386/trunk/3.3.1/binary/trunk"

Martin Friebe

2020-01-07 17:00

manager   ~0120251

Ok, so if you are sure that by the time the exception is hit, the "step over" has long gone and failed to stop, then this is a bug either in FPC or in GDB.
Neither of which I can fix in the IDE.

Notable there is a similar issue between gdb and fpc, where "step over" stops inside the procedure which it was meant to step over (i.e. performs a step in).
That could be related, but the cause of it is not known (and may need knowledge about gdb's inner workings)


I had a brief look at the readelf dump files.
The problem is I do not know, what information gdb uses to find the "end of stepping" location.

Changes in the dump file are

* line info // objdump can give you a decoded version, if you want to look yourself
In your "working example" the step starts at 1143 (breakpoint) and ends in line 1156.

The bad line info has line 1143, and then next line 1157
The good line info has line 1143, 1156 and 1157

In either case there would be a line after 1143 at which to stop.
I do not know why gdb does not.
I "know" (as in rumour has it) that gdb does detect the "epilogue" (the special last line of a procedure, where the "stackframe" (storage for locals) is removed). But again, I would not know why gdb would then mess up stepping.

Otherwise the line info looks correct to me. (Up to that line, I have not bothered to check all the other lines, obviously lines below will have changed....)

* debug_frame
Which I can not comment on. I would need to read up the dwarf standard on this.
Afaik it relates to finding where registers are stored on the stack, so when unrolling the stack, the values in parent callers can be restored.

I do not know if gdb attempts some smart whatever based on those, when stepping....
Not sure if related, but I recently saw which relates to the frame info.

If GDB for some reason uses info from this section, then any issue relating to that data could be related to this issue.....

* debug info
That just reflects the changed address...

Note that
- 0036520 is reported for linux. I do not know if it applies for win64 too.
- The "step in" instead of "over" issue, has been observed on win64 (but 64bit only) / and I do not know if it occurs on *nix.

There is a patch, so you can try if it affects your case.

Martin Friebe

2020-01-07 17:04

manager   ~0120252

This issue appears to be either FPC or GDB.

It can not be fixed in the IDE.
I also do not see any workaround that could be applied (like sending special instructions to gdb).

I therefore would resolve it as "not fixable"

It could be moved to FPC, if you want to report it against fpc. But I would suggest a fresh report.

The other issues I described (exception in 2nd thread), is not topic of this report. It also is known, and on my extended todo list.

Martin Friebe

2020-01-12 18:31

manager   ~0120369

"not fixable" as part of the IDE.


2020-03-27 10:06

reporter   ~0121729

Related bug report at FPC side :

Issue History

Date Modified Username Field Change
2020-01-06 14:12 Cyrax New Issue
2020-01-06 14:12 Cyrax Status new => assigned
2020-01-06 14:12 Cyrax Assigned To => Martin Friebe
2020-01-06 14:12 Cyrax File Added:
2020-01-06 17:37 Martin Friebe Note Added: 0120236
2020-01-07 04:01 Cyrax Note Added: 0120247
2020-01-07 04:07 Cyrax File Added:
2020-01-07 04:07 Cyrax Note Added: 0120248
2020-01-07 04:40 Cyrax File Added: udcutils assembler and node dump - steps do not
2020-01-07 04:40 Cyrax File Added: udcutils assembler and node dump - added dummy variable - steps
2020-01-07 04:51 Cyrax File Added: steps work -
2020-01-07 04:51 Cyrax File Added: steps do not work -
2020-01-07 04:53 Cyrax Note Added: 0120249
2020-01-07 17:00 Martin Friebe Note Added: 0120251
2020-01-07 17:04 Martin Friebe Status assigned => feedback
2020-01-07 17:04 Martin Friebe LazTarget => -
2020-01-07 17:04 Martin Friebe Note Added: 0120252
2020-01-12 18:31 Martin Friebe Status feedback => resolved
2020-01-12 18:31 Martin Friebe Resolution open => not fixable
2020-01-12 18:31 Martin Friebe Widgetset GTK 2 => GTK 2
2020-01-12 18:31 Martin Friebe Note Added: 0120369
2020-03-27 10:06 Cyrax Note Added: 0121729