site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 18, 2009, at 08:07, IainS wrote: Hello, I have read tn2123 and the crash report man page. -- Joe Ranieri _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Whilst crash reporter is a very useful and wonderful item - there are certain circumstances in which it can get in the way. In particular, if one is regression-testing on a multi-core machine (i.e. you *expect* a lot of crashes) then there is a problem where the crash report mechanism gives out a "too many crashes" log message and seems to stall for a while. This also sometimes gives false results on the testing (i.e. it seems that an executable has failed by timing out). The latter seems to indicate that I can disable crash reporting "for everything" involving a re-boot (by setting appropriate flags in launchd controls). I'd much prefer to disable the crash reports only for the sessions that are unit testing (since I find that crash reports are generally helpful). Also a re-boot per change is not terribly attractive... Does anyone know of a more selective way of dealing with this? On Leopard and later, you can simply install a signal handler for whatever signals you want to trap (just remember to only use signal safe code!). Prior to Leopard, you would need to fiddle with the mach exception port. See <http://lists.apple.com/archives/Cocoa-dev/2005/Aug/msg01986.html
for details about the mach exception handling stuff. This email sent to site_archiver@lists.apple.com