User forums > Using Code::Blocks

Killing file manager when debugger is stopped

(1/2) > >>

bnilsson:
When the CB debugger is stopped, my file manager is killed, clearing the desktop and all applications.
I thought this was fixed?
My CB rev is 3194.

afb:

--- Quote from: bnilsson on November 08, 2006, 06:45:18 pm ---I thought this was fixed?

--- End quote ---

I thought so too, was this with the patched wxWidgets ?
http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

afb:
Also, if this is the same as the previous bug, it is not just the file manager (Finder.app) but the entire session manager (Login.app) - which is much more severe, and loses more data. :-(

http://developer.berlios.de/bugs/?func=detailbug&bug_id=8950&group_id=5358

afb:
Hmm, just thought about it and the patch was only for Intel anyway...
We'll need to add some safety checks to the "debugger stop" command!

afb:
Hmm, sending a SIGKILL to PID=-1 will also do that you mention:


--- Code: ---     The following pids have special meanings:
     -1      If superuser, broadcast the signal to all processes; otherwise
             broadcast to all processes belonging to the user.

--- End code ---

This seems to be a pretty nasty setup, considering what wxMac does:


--- Code: ---    // 0 means execution failed. Returning non-zero is a PID, but not
    // on Mac where PIDs are 64 bits and won't fit in a long, so we
    // return a dummy value for now.
    return ( err == noErr ) ? -1 : 0;

--- End code ---

--- Code: ---    // Semi-macros used for return value of wxMacExecute
const long errorCode = ((flags & wxEXEC_SYNC) ? -1 : 0);
const long successCode = ((flags & wxEXEC_SYNC) ? 0 : -1); // fake PID

--- End code ---


Add a Code::Blocks that only checks for PID=0, and you have a problem...

Navigation

[0] Message Index

[#] Next page