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

Stop debugger in MacOSX

(1/2) > >>

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:

--- Quote ---PID    TT STAT TIME     COMMAND
.
.
8511  ??  Z      0:00.00 (gdb-powerpc-appl)
--- End quote ---
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:

--- Quote from: bnilsson on December 17, 2006, 12:00:28 pm ---The problem with stopping the debugger in MacOSX is apparently still not solved.

--- End quote ---

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:

--- Quote from: bnilsson on December 18, 2006, 12:57:47 pm ---I am using MacPorts for wxWidgets, what is the best way to apply the patch?

--- End quote ---

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 {

--- End code ---

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


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

--- End quote ---

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).

Navigation

[0] Message Index

[#] Next page