Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Stoppable gdb for MacOSX - when?
bnilsson:
When can we expect a stoppable GDB process from within CB for MacOSX?
I will have to put CB aside and go back to CodeWarrior until this is working.
afb:
I'm not sure what the timeline of the wxExecute replacement is... ?
If you can come up with a PID workaround for Mac OS X before then,
it might be doable to add that in a __WXMAC__ block in the meantime.
But the default wxMac implementation will return -1 for the process ID,
regardless of what the real number was when invoking the gdb backend.
Pecan:
--- Quote from: afb on February 10, 2007, 11:20:47 am ---I'm not sure what the timeline of the wxExecute replacement is... ?
If you can come up with a PID workaround for Mac OS X before then,
it might be doable to add that in a __WXMAC__ block in the meantime.
But the default wxMac implementation will return -1 for the process ID,
regardless of what the real number was when invoking the gdb backend.
--- End quote ---
Something like the following might work. I issue a "ps x" command and capture the output, then scan the output for the program/pid of interest.
In this particular code, I'm looking for the tty (second ps output field) of the sleep command which was started by a "xterm -e sleep 80000" command.
--- Code: ---+// ----------------------------------------------------------------------------
+wxString GDB_driver::GetConsoleTty(int ConsolePid)
+// ----------------------------------------------------------------------------
+{
+ // execute the ps -x command and read PS output to get the /dev/tty field
+
+ unsigned long ConsPid = ConsolePid;
+ wxString psCmd;
+ wxArrayString psOutput;
+ wxArrayString psErrors;
+
+ psCmd << wxT("ps x");
+ m_pDBG->Log(wxString::Format( _("Executing: %s"), psCmd.c_str()) );
+ int result = wxExecute(psCmd, psOutput, psErrors, wxEXEC_SYNC);
+ psCmd.Clear();
+ if (result != 0)
+ { psCmd << wxT("Result of ps x:") << result;
+ m_pDBG->Log(wxString::Format( _("Execution Error:"), psCmd.c_str()) );
+ return wxEmptyString;
+ }
+
+ wxString ConsTtyStr;
+ wxString ConsPidStr;
+ ConsPidStr << ConsPid;
+ //find task with our unique sleep time
+ wxString uniqueSleepTimeStr;
+ uniqueSleepTimeStr << wxT("sleep ") << 80000 + ::wxGetProcessId();
+ // search the output of "ps pid" command
+ int knt = psOutput.GetCount();
+ for (int i=knt-1; i>-1; --i)
+ { psCmd = psOutput.Item(i);
+ m_pDBG->Log(wxString::Format( _("PS result: %s"), psCmd.c_str()) );
+ // find the pts/# or tty/# or whatever it's called
+ // by seaching the output for our pid in character
+ // The output of ps looks like:
+ // PID TTY STAT TIME COMMAND
+ // 8779 pts/3 Ss+ 0:00 sleep 600000
+ //if (psCmd.Contains(ConsPidStr))
+ if (psCmd.Contains(uniqueSleepTimeStr))
+ { ConsTtyStr = psCmd.Mid( ConsPidStr.Length()+2);
+ ConsTtyStr = wxT("/dev/")+ConsTtyStr.BeforeFirst(' ');
+ m_pDBG->Log(wxString::Format( _("TTY is[%s]"), ConsTtyStr.c_str()) );
+ return ConsTtyStr;
+ }//if
+ }//for
+
+ knt = psErrors.GetCount();
+ for (int i=0; i<knt; ++i)
+ m_pDBG->Log(wxString::Format( _("PS Error:%s"), psErrors.Item(i).c_str()) );
+ return wxEmptyString;
+}
--- End code ---
bnilsson:
I wonder...
After a debug session ends, I find the following process with 'ps x':
16989 ?? Z 0:00.00 (gdb-powerpc-appl)
Is this a candidate for the process to be stopped?
If I quit CB it disappears, and it does not appear again until CB is restarted and a new debug session is started and terminated.
I cannot kill it by 'kill -9 16989', nothing happens.
So I guess trying to do the same from within the program would not work either.
Can it be stopped by any other method?
bnilsson:
Some more:
When waiting at a breakpoint, 'ps x' shows
18159 ?? S 0:02.62 /usr/libexec/gdb/gdb-powerpc-apple-darwin -nx -fullname -quiet -args bin/Debug/wxProject.app/Contents/MacOS/wxProject
After the debugging is terminated, either by Continue or Stop Debugger, 'ps x' shows
18159 ?? Z 0:00.00 (gdb-powerpc-appl)
apparently a zombie process that I cannot get rid of by command line.
If I do 'kill -9' on the process before it has become a zombie (standing at the breakpoint), it immidiately becomes one (a zombie).
Continuing the debugging after that crashes CB altogether, which is not strange.
Any suggestions would be appreciated.
Navigation
[0] Message Index
[#] Next page
Go to full version