Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: tiwag on February 09, 2006, 06:39:32 pm

Title: Debugging issues
Post by: tiwag on February 09, 2006, 06:39:32 pm
in the svn rev 1966 the "Run to cursor" functionality is broken during debugging sessions.
it only works once if you didn't start already a debugging session.

also i get sometimes (often) debugger hangs where only a "Stop debugger" can be done, all other controls like step, step into, ... aren't available anymore when debugging a multi-file project or debugging some library functions (static lib)

[edit] more info ...
it seems to hang reproducible, when i have a dereferenced pointer to a custom structure in my watches list and the debugger stops at a breakpoint, in whose context my pointer to the structure isn't defined.

using gcc 3.4.4 & gdb 6.3-2 , running on WinXP
Title: Re: Debugging issues
Post by: tiwag on February 10, 2006, 07:43:26 am
the disassembly window doesn't show anything anymore  :shock:

i stepped back to rev 1870 where debugging is working reliable
Title: Re: Debugging issues
Post by: mandrav on February 10, 2006, 08:51:43 am
Let me check. This must be my mistake...
Title: Re: Debugging issues
Post by: tiwag on February 11, 2006, 11:21:48 am
attached you can find a small test program which demonstrates a case,
where the debugger hangs if you use any recent C::B version (last tested with rev 1981)

the problem is somehow related to the watches-window,
there is no hang if the watches-window isnt active during debugging.

[edit] more info
set your debugger-plugin to watch
* local variables and
* function arguments


[attachment deleted by admin]
Title: Re: Debugging issues
Post by: mandrav on February 11, 2006, 01:34:48 pm
Thanks tiwag :)
Title: Re: Debugging issues
Post by: mandrav on February 11, 2006, 08:54:12 pm
That was a bit harder than I thought, but it's now fixed :)
Title: Re: Debugging issues
Post by: tiwag on February 11, 2006, 09:15:27 pm
yeah - it works well with rev 1984

only the F4 (Run to cursor) issue is left till now
Title: Re: Debugging issues
Post by: mandrav on February 11, 2006, 10:01:55 pm
Quote from: tiwag on February 11, 2006, 09:15:27 pm
yeah - it works well with rev 1984

only the F4 (Run to cursor) issue is left till now

...which works fine here. Are you doing anything special?
Title: Re: Debugging issues
Post by: tiwag on February 11, 2006, 10:08:05 pm
have you tried to position the cursor further down in your code and then press F4 again, when you're already debugging ?!

for me F4 (Run to cursor) does work only once, when in non-debugging-state

i'm not aware of doing something special

F4 could be used in pre 1873 versions also during debugging sessions which is quite convenient
Title: Re: Debugging issues
Post by: mandrav on February 11, 2006, 10:23:13 pm
Quote from: tiwag on February 11, 2006, 10:08:05 pm
have you tried to position the cursor further down in your code and then press F4 again, when you're already debugging ?!

for me F4 (Run to cursor) does work only once, when in non-debugging-state

Well, that should be enough ;)
Thanks.
Title: Re: Debugging issues
Post by: tiwag on February 12, 2006, 09:20:24 am
Quote
Well, that should be enough ;)

well -  :shock:

actually i found out, that pressing F4 during an active debugging session actually set's a temporary breakpoint, but the run command isn't fired - but it works when you press Ctrl-F7 (after pressing F4)
Title: Re: Debugging issues
Post by: tiwag on February 12, 2006, 02:53:12 pm

regarding the problem, Run-to-cursor ( F4 ) does set a "tbreak" but doesn't continue debugging:

the problem is, that
DebuggerDriver::RunQueue()   (in plugins\debuggergdb\debuggerdriver.cpp)
sets
m_ProgramIsStopped = false;
regardless of the command and/or the actual state but in
DebuggerGDB::RunToCursor()  (in plugins\debuggergdb\debuggergdb.cpp)
you call afterwards
Continue();
which runs 
DebuggerGDB::RunCommand(int cmd)   
which tests the same flag by calling 
!IsStopped()   
in order to proceed or just leave the function without action.

in order to test the above said i did the following patch,
which doesn'tn set
m_ProgramIsStopped = false;
in case of the current command is a temporary breakpoint request.


Code
Index: D:/devel/CodeBlocks/trunk/src/plugins/debuggergdb/debuggerdriver.cpp
===================================================================
--- D:/devel/CodeBlocks/trunk/src/plugins/debuggergdb/debuggerdriver.cpp	(revision 1986)
+++ D:/devel/CodeBlocks/trunk/src/plugins/debuggergdb/debuggerdriver.cpp	(working copy)
@@ -96,7 +96,8 @@
     {
         m_QueueBusy = true;
         m_pDBG->SendCommand(CurrentCommand()->m_Cmd);
-        m_ProgramIsStopped = false;
+        if (!CurrentCommand()->m_Cmd.StartsWith(_T("tbreak ")))
+            m_ProgramIsStopped = false;
     }
 
     // Call Action()


with this patch F4 works ok, but it is certainly not the right patch for solving this problem generally,
that is beyond my scope ... only want to share my results of investigation
Title: Re: Debugging issues
Post by: mandrav on February 12, 2006, 10:50:36 pm
Fixed in SVN.
Title: Re: Debugging issues
Post by: tiwag on February 13, 2006, 09:22:11 am
Thanks Yiannis - the debugging works awesome now !

btw. is it correct in all cases just not to test the flag
(by NOT calling) !IsStopped()   
in  DebuggerGDB::RunCommand(int cmd)  ???

shouldn't be set the flag according to the real state of the debugger ?
sorry if this is a dumb question, but obviously i didn't well understand the reason for this flag.
Title: Re: Debugging issues
Post by: mandrav on February 13, 2006, 10:46:02 am
IsStopped() is true when the debugging session isn't running or if it's idle.
In RunCommand() it's not necessary to check for it, because this function is only called by other functions (it's like a dispatcher) which check for the running state themselves.
So, yes, it's safe not to check for it inside RunCommand()...