Stop debugger in MacOSX

[bnilsson]

The problem with stopping the debugger in MacOSX is apparently still not solved. It is a major showstopper, at least for me, for using CB for anything serious. I have to exit CB and restart, which takes LONG time compared to most other applications (why?)
 
debuggerGDB::Stop() is asking for the debugger process pid, and gets -1 instead of the real pid. If this is used in wxKill, it stops all processes on the desktop, which is not desirable.

If I look for a plausible pid manually using the Terminal, I see something like this:

PID    TT STAT TIME     COMMAND
.
.
8511  ??  Z      0:00.00 (gdb-powerpc-appl)

which I guess might be the target. "Z" means "dead" or "zombie", and if I try to kill it manually by "kill -9 8511" nothing happens, it is still there. Same thing if I add a wxDialog and enter this pid manually into ::Stop() for the wxKill(). Same thing if I make "su" and try to kill it.
If I quit CB it disappears, and it is not there if I run CB without debugging.

Am I right in identifying the correct dbg process?
Can anybody tell me why this process cannot be removed?

[afb]

The problem with stopping the debugger in MacOSX is apparently still not solved.

No, the only workaround applied was avoiding to pass -1 along to kill... (=> killall)

I didn't look further into patching this (wxExecute) for Mac OS X, since there was a
rewrite in progress to avoid wxExecute altogether and use Code::Blocks-specific code.

But to be honest I'm not sure what happened to it, maybe we need an interim fix ?

[afb]

Just double-checking: you did patch your wxWidgets 2.6.3, right ?
http://sourceforge.net/tracker/index.php?func=detail&aid=1588883&group_id=9863&atid=309863

This fix is absolutely necessary for Mac OS X 10.4, which is why my
DarwinPorts packages uses the "wxMac" port instead of "wxWidgets"...


edit: Mac OS X 10.4 on Intel, that was. It's not needed on PowerPC.

[bnilsson]

I am using MacPorts for wxWidgets, what is the best way to apply the patch?
"port install" builds it silently, so I never see the source.

[afb]

I am using MacPorts for wxWidgets, what is the best way to apply the patch?

The "best" way is probably to set up your own local ports tree,
or whine on the new MacPorts developers to patch their version.
(see the Code::Blocks wiki on how to build your own wxMac port)

Anyway, you need this file - which should go in wxWidgets*/files/:
http://www.algonet.se/~afb/wx/patch-polling.diff
(you might need to edit the top two lines to say "wxWidgets-2.6.3")

And then you need to edit the wxWidgets*/Portfile to include this patch:

Code

extract.only	${name}-${version}${extract.suffix}
patchfiles		patch-polling.diff
post-extract {

* usually lives in something like: /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/graphics/wxWidgets

"port install" builds it silently, so I never see the source.

You can use port install -d wxWidgets, if bored. :-)

MacPorts isn't seeing much development since the name change,
but I hope they will get around to fixing their bugs some day... ?
Meanwhile, I'm using my own local DarwinPorts tree that I have.

It builds OK for wxMac/wxGTK/wxMSW on Mac OS X 10.4 (Intel).

[afb]

But I remembered incorrectly, and the patch was only for Intel.
On PowerPC it should use the same code as before, so it probably
won't help you with the issues you are seeing on Mac OS X 10.4 :-(

[afb]

I think I'll just add some crude hack to look for the special wxMac case
of -1 for a PID, and try to find the real one with ps or something...

Code

ps -a -x -c -o command,pid,ppid | grep $$ | grep gdb

But I'm not really sure what the parent pid is for a LSOpenFromURL ?
Will do some test code I think, and you can tell me which one works.