On 22 Sep 2009, at 18:01, Jens Alfke wrote:
On Sep 22, 2009, at 9:47 AM, Mark Woods wrote:
However, when the task crashes, a Crash Reporter dialog appears
which could be confusing for the user and ugly if several appear at
once. Is there any way to suppress these messages and prevent them
from appearing?
I'm pretty sure there is, but I don't see anything relevant in
NSTask.h. It's possible you have to use lower-level calls like fork/
exec to get that degree of control.
This is getting a bit off-topic, but I don't think you'll be able to
do that even at that level. The crash report mechanism, AFAIK, works
by using the Mach exception port for the process to trigger a crash
report when it crashes.
If you was *your* process that crashed, on "normal" UNIX-like systems
you can use signal handlers to catch the crash and do something about
it. Likewise, on a normal UNIX-like platform you'd get a SIGCHLD from
the system and you could check the process exit status. Or you could
act as a debugger using the ptrace() API.
On OS X though, you can't (or couldn't, last I checked which was some
time ago) intercept the system crash reporter using signal-related
APIs because it's triggered by the lower-level Mach exception port.
Even if you somehow handle the signal (in the parent or the child
process), the crash reporter is still triggered via the Mach exception
port. And when I last looked at the sources for the OS X version of
GDB, it was somewhat more hairy than the simple ptrace() API might
lead you to believe... plus in any case QuickTime is probably one of
those programs that acts to defend itself against debugging.
Of course, I haven't looked to see if any of this has changed on Snow
Leopard...
The task checks the validity of certain files and in some cases,
the task could definitely crash if the data is corrupt - that is
the whole purpose of launching a separate task. This is not a
problem as the application notifies the user if the task was not
successful.
This kind of rings an alarm bell in my head. The problem is that, if
your subtask isn't explicitly handling invalid data, it could do far
worse things than simply crash.
Agreed. The OP should validate the data in his own code first if
there is any risk that it might be "booby-trapped" somehow.
*And* report the crashes to Apple as they're clearly bugs.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
