Bug 111828 - Debugger fronend in incorrect state
Summary: Debugger fronend in incorrect state
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: CPP Debugger (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-31 18:44 UTC by leon pollak
Modified: 2009-01-23 23:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description leon pollak 2005-08-31 18:44:08 UTC
Version:           3.2.90 (using KDE KDE 3.3.2)
Installed from:    Fedora RPMs
OS:                Linux

Starting debugger kdevelop suppose that gdb is in running state. This is incorrect in some cases. In my case starting gdb and loading .gdbinit is the starting operation. Nothing is still loaded and running.
Now, I press Cntrl-C ("stop" button with 2 verticals) and now I can enter commands. Good.
My .gdbinit has macro which sets program counter and runs some program, which nust run 1s before my application get loaded. The script contains "continue" command and waits for Ctrl-C to be pressed.
But I can not press it as the front end thinks the gdb is in prompt!
Comment 1 Vladimir Prus 2005-09-01 11:06:25 UTC
Let me clarify: your .gdbinit has "continue" and so when gdb is loaded it's immediately in "running" state. You want to send Ctrl-C to gdb, but cannot, because kdevelop only shows "pause execution" button when he things the application is running, while it things it's stopped. Right?

First question: why do you need this "continue" + "Ctrl-C" combination?
Comment 2 leon pollak 2005-09-01 11:12:35 UTC
Small correction - after loading gdb I run macro, which does what ou described.
To your question - the unit has the "boot loader" which initializes RAM and sets some memory values. Macro starts with making HW reset to the target. Then I need to let the CPU to run a bit to execute boot loader and set RAM and values. Next, I do Ctrl-C and now can send gdb commands to download the code via BDM (the special interface for debugging) and finally "continue" to run the downloaded application.
Comment 3 Vladimir Prus 2005-09-07 12:30:48 UTC
So, Ctrl-C is to give the boot loader some time, right? Why don't you just use
"shell sleep XXX" in your gdb macro, followed by the gdb command to download the code, followed by "continue"?
Comment 4 leon pollak 2005-09-07 13:02:17 UTC
Because of 2 reasons:
1. To download via BDM I neet to stop the CPU. Only in the stop it can accept commands.
2. "shell" command is executed in parallel with gdb - it does not wait for it to finish.

But IMHO, we "lost here the baby". 
I spoke about the front end been not synchronized with the gdb. And, BTW, I have now the more simple case - I start the debugger and it is already in busy state, while actually gdb is in prompt. I think - this is the case. 
Now, when severe lost of sync occurs, I need to reopen the kdevelop, because the front end is not operational any more at all. And I observed several times the situation when this lost of sync caused the X-Windows to crash when I reopen the kdevelop.
Comment 5 Vladimir Prus 2005-12-08 09:39:55 UTC
So, as a final clarification:
1. You run your macro that contains "continue"
2. KDevelop thinks the application is not running, so does not allow you to send "Ctrl-C". Right?
Comment 6 leon pollak 2005-12-13 12:46:17 UTC
Sorry for the late answer - I was out of the office...
Generally - yes.
In details:
1. Consider the .gdbinit script, which contains the 'load' command. This command execution via BDM, serial line or similar takes significant time -10-20s. During this time, gdb is busy, kdevelop thinks it is not.
2. If script contains "contine", KDevelop does not see that gdb is busy.

Hope this helps. If no, let me know - i shall try to elaborate some better example.
Comment 7 leon pollak 2005-12-14 17:19:05 UTC
Vladimir, here is the worst case example.
I have the following text in the .gdbinit file:        set mpcbdm_adapter 2
        target mpcbdm 0
        set mpcbdm_dflush off
        set $pc=0xfff00100
        shell ./tftp_load &
        continue
If the tftp server does not answer, the tftp_load script waits printing dots (I think this is irrelevant, but still...)

Now, when I run this, I see dots and there is no way to cancel this, as KDevelop is in stopped state.

BUT!!!!
When I stop the debugger (by pressing red "X" button), this causes the X-windows to crash!
I checked this several times - the result is stable, X crashes and restarts. No error messages are produced.

Best Regards
Comment 8 Vladimir Prus 2006-01-24 10:41:34 UTC
It looks like there's no 100% nice fix, because in general, it's not possible to ask gdb if it's running a command or just busy itself, like reading huge symbol tables.

I think I'll either make the "Interrupt" button always enabled (like is done in DDD), or make it enabled after certain timeout.
Comment 9 leon pollak 2006-01-24 11:18:05 UTC
I vote for "always enabled" with both hands. There is no harm at all if one presses "Interrupt" (sends Ctrl-C), while gdb is not busy.

And, please, can you estimate when this will be available? (It is very uncomfortable to switch to compile in KDevelop and debug in DDD).

Thanks ahead a lot.
Comment 10 Vladimir Prus 2006-01-24 11:27:56 UTC
Speaking about "Interrupt" button in gdb window -- I'll commit this change in half an hour. I'll also need to find where the "Interrupt" menu item got disabled.

There are other followup changes -- like preventing entering new gdb commands when the previous one has not finished, but that's not part of this bug report.
Comment 11 leon pollak 2006-01-24 11:33:44 UTC
BTW, I don't know how this is done in DDD, but it never is confused by an incorrect gdb state - it does not display the prompt till gdb is ready to receive a command. Again, I don't know, but I noticed that when gdb is busy sending any command does nothing - it does not reply, which may be an indication...
Sorry...
Comment 12 Vladimir Prus 2006-01-24 11:39:12 UTC
Yes, I noticed that fact that DDD will accept the comamnds even if gdb is busy, and that's something I don't like and will eventually fix.
Comment 13 Vladimir Prus 2006-01-24 12:12:43 UTC
SVN commit 501919 by vprus:

Don't disable the "Interrupt" menu item and the "Interrupt" button
in gdb window when gdb is in "paused" state. The problem is that gdb
does not allow to correctly test if application is running or not, especially
when application was started by user-defined command containing "continue" 
inside. In such cases it's not possible to stop the application at all.

The problem with this patch is that after interrupting the application,
the current source line is not shown. That will be fixed later,
when I port everything to MI.

CCBUG: 111828


 M  +1 -1      gdbcontroller.cpp  
 M  +4 -2      gdboutputwidget.cpp  
 M  +0 -1      kdevdebugger.rc  


--- branches/kdevelop/3.4/languages/cpp/debugger/gdbcontroller.cpp #501918:501919
@@ -382,7 +382,7 @@
             delete cmdList_.take(i);
     }
 
-    if (dbgProcess_ && stateIsOn(s_appBusy))
+    if (dbgProcess_)
         dbgProcess_->kill(SIGINT);
 }
 
--- branches/kdevelop/3.4/languages/cpp/debugger/gdboutputwidget.cpp #501918:501919
@@ -137,15 +137,17 @@
         m_userGDBCmdEditor->setEnabled(false);
         return;
     }
+    else
+    {
+        m_Interrupt->setEnabled(true);
+    }
 
     if (statusFlag & s_appBusy)
     {
-        m_Interrupt->setEnabled(true);
         m_userGDBCmdEditor->setEnabled(false);
     }
     else
     {
-        m_Interrupt->setEnabled(false);
         m_userGDBCmdEditor->setEnabled(true);
     }
 }
--- branches/kdevelop/3.4/languages/cpp/debugger/kdevdebugger.rc #501918:501919
@@ -67,7 +67,6 @@
     <Action name="debug_memview"/>
   </enable>
   <disable>
-    <Action name="debug_pause"/>
     <Action name="debug_core"/>
     <Action name="debug_attach"/>
   </disable>
Comment 14 Andreas Pakulat 2007-12-01 01:14:56 UTC
Valdimir can this bug be closed as fixed?
Comment 15 Andreas Pakulat 2009-01-23 23:08:24 UTC
assuming fixed as there's a lot better support since this was done.