View Issue Details

IDProjectCategoryView StatusLast Update
0022230LazarusDebuggerpublic2012-06-14 14:30
ReporterLudo Brands Assigned ToMartin Friebe  
Status closedResolutionfixed 
Product Version1.1 (SVN) 
Target Version1.0.0Fixed in Version1.1 (SVN) 
Summary0022230: Debugger hanging for minutes at breakpoint
DescriptionWith svn 37511 encountered several instances where the debugger would hang for minutes before moving on. This is not related to getting line numbers but to the IDE requesting a very wide address range to disassemble. The debug output window confirms that. When finally the disassembled data arrives, it is followed by a huge number (sometimes >100) of short disassembly requests. Attached log shows he problem clearly. Search for "-data-disassemble -s 5528815 -e 5586648 -- 0" to get a very long hang.
TagsNo tags attached.
Fixed in Revision37609, 37643
Attached Files


2012-06-08 13:29 (26,960 bytes)

Martin Friebe

2012-06-09 22:26

manager   ~0060408

Last edited: 2012-06-09 23:46

Please recompile with DBG_VERBOSE defined (this can not be given via --debug-enable).

Keep the --debug-enable (or other defines) as they are: DBGMI_QUEUE_DEBUG, DBG_CMD_ECHO, ...

Then reproduce the log.

Edit: Try using DBG_CMD_ECHO_FULL instead of DBG_CMD_ECHO

Martin Friebe

2012-06-10 00:12

manager   ~0060410

The issue reveals 2 independent problems:

1) If the user requests, continue stepping or running, the debugger *should* cancel all requests that will no longer be needed. That is the user does not want to see locals, watches, assembler ..., if he wants to step.

The disassemble is cancelled (which is correct).
But somewhere this is not fully implemented. The missing data is detected and the cancelled request is re-issued. This should not be.
Due to this pressing F7,F8,F9 before the disassembler finishes leads to a full repeat, until the disassembler gets a change to finish.

2) The debugger request a large address range.
This needs the requested feedback (triggering above part 1 is not needed)
From what I see now, this may be an issue caused by a gdb oddity.

The first range requested is correct (it was calculated to be the begin of the subroutine) (comma inserted for readability):

-data-disassemble -s 5,586,256 -e 5,586,616 -- 1
^done,asm_insns=[src_and_asm_line={line="2509",file="./fcl-db/src/base/db.pas", line_asm_insn=[{address="0x00545cd5",func-name="VARARRAYSAMEVALUES",

0x00545cd5 = 5,528,789

So gdb returned data, that was not wanted. Probobly the previous data with line info... except:
Some of the addresses in between will return data for other functions with line info, some will not. There is no way to know.

The requested address actually is the begin of TCUSTOMCONNECTION__LOADED. And that apparently has no line-info.

In this case, iterating backward, could be better... But, still this is about finding the better way of guessing (since gdb does not reveal for sure)

Martin Friebe

2012-06-10 19:34

manager   ~0060420

Part 1 should be fixed in 37609

Issue History

Date Modified Username Field Change
2012-06-08 13:29 Ludo Brands New Issue
2012-06-08 13:29 Ludo Brands Status new => assigned
2012-06-08 13:29 Ludo Brands Assigned To => Marc Weustink
2012-06-08 13:29 Ludo Brands File Added:
2012-06-08 13:29 Ludo Brands Widgetset => Win32/Win64
2012-06-09 22:13 Martin Friebe Assigned To Marc Weustink => Martin Friebe
2012-06-09 22:26 Martin Friebe LazTarget => -
2012-06-09 22:26 Martin Friebe Note Added: 0060408
2012-06-09 22:26 Martin Friebe Status assigned => feedback
2012-06-09 23:13 Martin Friebe Note Edited: 0060408
2012-06-09 23:46 Martin Friebe Note Edited: 0060408
2012-06-10 00:12 Martin Friebe Note Added: 0060410
2012-06-10 19:34 Martin Friebe Note Added: 0060420
2012-06-14 13:58 Martin Friebe Fixed in Revision => 37609, 37643
2012-06-14 13:58 Martin Friebe Widgetset Win32/Win64 =>
2012-06-14 13:58 Martin Friebe Status feedback => resolved
2012-06-14 13:58 Martin Friebe Fixed in Version => 1.1 (SVN)
2012-06-14 13:58 Martin Friebe Resolution open => fixed
2012-06-14 13:58 Martin Friebe Target Version => 1.0.0
2012-06-14 14:30 Ludo Brands Status resolved => closed