View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0022230||Lazarus||Debugger||public||2012-06-08 13:29||2012-06-14 14:30|
|Reporter||Ludo Brands||Assigned To||Martin Friebe|
|Product Version||1.1 (SVN)||Product Build|
|Target Version||1.0.0||Fixed in Version||1.1 (SVN)|
|Summary||0022230: Debugger hanging for minutes at breakpoint|
|Description||With 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.|
|Tags||No tags attached.|
|Fixed in Revision||37609, 37643|
log8.zip (26,960 bytes)
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
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
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)
||Part 1 should be fixed in 37609|
|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: log8.zip|
|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|