Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

debugger stop button on Linux console pgm crashes CB

<< < (3/4) > >>

Pecan:

--- Quote from: mandrav on February 07, 2007, 02:26:03 pm ---
--- Quote from: pecan ---@Yiannis
Do you want to fix this, or would you care for me to try and find a place to add a wxCriticalSection and see how it goes.
--- End quote ---

Although I have failed to reproduce a crash, I will have a look.
And no threads are used in the debugger plugin AFAIR...

--- End quote ---


--- Code: ---     m_pProcess = new PipedProcess((void**)&m_pProcess, this, idGDBProcess, true, cwd);
    Manager::Get()->GetMessageManager()->AppendLog(m_PageIndex, _("Starting debugger: "));
    m_Pid = wxExecute(cmd, wxEXEC_ASYNC, m_pProcess);

--- End code ---

Arn't the above lines creating an asynchronous process that enters DebuggerGDB via OnGDBOutput and OnGDBError as if they are a separate thread?

The GDB traces would suggest that.

mandrav:

--- Quote from: pecan ---Arn't the above lines creating an asynchronous process that enters DebuggerGDB via OnGDBOutput and OnGDBError as if they are a separate thread?

--- End quote ---

Technically, no, a separate process is not a different thread.
Let me have a look at your findings though.

Pecan:
Here is a little console pgm that will crash ever time you hit the Stop button.


--- Code: ---#include <iostream>
#include <cstdlib>
#include <cstring>

using namespace std;

int upstring(char *value);


int main()
{
        char value[81]={'\0'};
        int upper_count;
        do
    {   cout << "Please type in a String (max. 80 characters): ";
        cin.getline(value, 80);
        upper_count = upstring(value);
        cout << upper_count << " characters are converted" << endl;
        cout << "The new string is now: " << value << endl;
    }while(upper_count);

  return EXIT_SUCCESS;
}

int upstring(char *value)
{
  int i=0;
  while(*value)
  {
    if(islower(*value))
    {
      *value=toupper(*value);
      i++;
    }
  value++;
  }
  return(i);
}                                                           

--- End code ---

Pecan:

--- Quote from: mandrav on February 07, 2007, 02:56:56 pm ---
--- Quote from: pecan ---Arn't the above lines creating an asynchronous process that enters DebuggerGDB via OnGDBOutput and OnGDBError as if they are a separate thread?

--- End quote ---

Technically, no, a separate process is not a different thread.
Let me have a look at your findings though.

--- End quote ---

Ok, I take it back. It's a process acting just like a thread.
Smells like a duck.....

Pecan:
Until Yiannis comes up with a better and more informed patch, here's a patch that fixes the debugger Stop Button crash on Linux.


--- Code: ---Index: debuggergdb.cpp
===================================================================
--- debuggergdb.cpp (revision 3558)
+++ debuggergdb.cpp (working copy)
@@ -1503,6 +1503,7 @@
 
 void DebuggerGDB::Stop()
 {
+    // m_pProcess is PipedProcess, m_Pid is GDBdebugger
     if (m_pProcess && m_Pid)
     {
         if (IsStopped())
@@ -1534,6 +1535,18 @@
         #endif
         }
     }
+   #if defined(__WXGTK__) //(pecan 2007/2/08)
+    // When PipedProcess and GDB are gone, we can finally
+    // release the GDB_driver
+    if ( !m_pProcess )
+    {
+        if (m_Pid>0)
+         wxKill (m_Pid, wxSIGTERM);
+        m_Pid = 0;
+        m_State.StopDriver();
+    }
+   #endif
+
 }
 
 void DebuggerGDB::ParseOutput(const wxString& output)
@@ -1937,7 +1950,17 @@
 //    m_pProcess = 0L;
 
     ClearActiveMarkFromAllEditors();
+
+   #if defined(__WXGTK__)
+    //(pecan 2007/2/07)
+    // Calling m_State.StopDriver() from here causes crashes since
+    // OnGDBOutput() has stacked multiple messages in the system.
+    // and needs the GDB_driver address.
+    //-m_State.StopDriver();
+   #else
     m_State.StopDriver();
+   #endif
+
     Manager::Get()->GetMessageManager()->Log(m_PageIndex, _("Debugger finished with status %d"), m_LastExitCode);
 
     if (m_NoDebugInfo)
@@ -2056,6 +2079,10 @@
     // allow others to catch this
     event.Skip();
 
+    #if defined(__WXGTK__)
+     Stop(); //(pecan 2007/2/08)
+    #endif
+
     // when a project is activated and it's not the actively debugged project,
     // ask the user to end debugging or re-activate the debugged project.
 
@@ -2064,6 +2091,13 @@
 
     if (event.GetProject() != m_pProject)
     {
+       #if defined(__WXGTK__) //(pecan 2007/2/08)
+        InfoWindow::Display(wxT("Warning"),
+                wxT("You changed the active project while the debugger was active\n"
+                "Debugging will terminate."),
+                6000, 1);
+
+       #else
         wxString msg = _("You can't change the active project while you 're actively debugging another.\n"
                         "Do you want to stop debugging?\n\n"
                         "Click \"Yes\" to stop debugging now or click \"No\" to re-activate the debuggee.");
@@ -2075,6 +2109,7 @@
         {
             Manager::Get()->GetProjectManager()->SetProject(m_pProject);
         }
+        #endif
     }
 }
 
@@ -2083,6 +2118,10 @@
     // allow others to catch this
     event.Skip();
 
+    #if defined(__WXGTK__)
+     Stop(); //(pecan 2007/2/08)
+    #endif
+
     // remove all search dirs sotred for this project so we don't have conflicts
     // if a newly opened project happens to use the same memory address
     GetSearchDirs(event.GetProject()).clear();
@@ -2100,11 +2139,17 @@
 
     if (event.GetProject() == m_pProject)
     {
+       #if defined(__WXGTK__) //(pecan 2007/2/08)
+        InfoWindow::Display( wxT("Warning"), _("The project you were debugging has closed.\n"
+                         "The debugging session will terminate immediately."),
+                         6000, 1);
+       #else
         cbMessageBox(_("The project you were debugging has closed.\n"
                         "The debugging session will terminate immediately."),
                     _("Warning"),
                     wxICON_WARNING);
         Stop();
+       #endif
     }
 }
 


--- End code ---

The result of all this is that the GDB_driver was being deleted while OnGDBOutput() still had about 5 GDB messages stackup up and being processed.

The delete in OnGDBTerminate() was swiping m_pDriver right out from under an active ParseOutput().

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version