site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com thanks, Iain _______________________________________________ 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... On 18 Jan 2009, at 14:38, Joe Ranieri wrote: 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. If I understand correctly - you're suggesting installing a signal handler (as normal) into the code. Unfortunately, that doesn't do what we need in this case: We want the code to abort (it does this intentionally to signify a failure - which is caught by the test-suite) - what I don't want is a crash report - the test framework already knows the code crashed ;-) To split hairs - actually, I wouldn't mind the crash report - the problem is that the mechanism is limiting test throughput - since crash reporter doesn't allow above a certain (unknown) number of crashes per second. When too many crashes per second arrive sometimes this gives a false failure indication (as the executable seems to disappear giving the impression that it timed out). This email sent to site_archiver@lists.apple.com