异常包装在OSX碳C的应用 [英] Exception wrapper for Carbon C app in OSX

查看:147
本文介绍了异常包装在OSX碳C的应用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我怎样才能有效地捕捉并在OSX Carbon程序处理从C段错误?

How can I efficiently catch and handle segmentation faults from C in an OSX Carbon application?

背景:我正在一个OSX Carbon程序。我必须从第三方调用库函数。由于线程问题的,该功能可以偶尔崩溃,通常是因为它是从一个线程更新自身,它得到了一些内部陈旧指针或处理,因为我从另一个查询。该函数是一个黑盒子给我。我希望能够调用该函数,但能够赶上,如果它已经崩溃并提供一个替代的回报。
在Windows中,我可以使用简单的Visual C和英特尔的C编译器的__try {}和__except。

Background: I am making an OSX Carbon application. I must call a library function from a third party. Because of threading issues, the function can occasionally crash, usually because it's updating itself from one thread, and it's got some internally stale pointer or handle as I query it from another. The function is a black box to me. I want to be able to call the function but be able to "catch" if it has crashed and supply an alternative return. In Windows, I can use the simple Visual C and Intel C compiler's __try{} and __except.

/* Working Windows Example */
__try { x=DangerousFunction(y);}
__except(EXCEPTION_EXECUTE_HANDLER) {x=0.0;} /* whups, func crashed! */

我试图使同一种崩溃捕手OSX的。我使用的一个非常大的应用程序纯C。我调用该函数每秒百万次,所以效率也很重要。 (IM pressively,在Windows __try()的开销是没法比的小!)

I am trying to make the same kind of crash-catcher for OSX. I am using pure C on a very large application. I call the function millions of times per second, so efficiency is very important too. (Impressively, the Windows __try() overhead is immeasurably small!)

这就是我已经试验了:

1)C ++异常。我不知道如果C ++异常捕捉段错误崩溃。而我的应用程序是目前C.我可以尝试包装和的#ifdefs使它C ++,但这是很多应用程序的工作,我不认为C ++异常将捕获的崩溃。

1) C++ exceptions. I am not sure if C++ exceptions catch the segfault crashes. And my app is currently C. I could try wrappers and #ifdefs to make it C++ but this is a lot of work for the app, and I don't think C++ exceptions will catch the crash.

2)信号+ setjump + longjmp的。我以为这会工作......这就是它的设计。但是,我建立了我的SEGV错误处理程序[其实我设置它为每一个信号!],并在碰撞过程中从来没有叫。我可以手动测试(和成功)呼吁提高(SEGV)时。但是崩溃似乎并不实际调用它。我的想法是,CFM应用程序不必访问完整的BSD信号,只有一个子集,而马赫应用程序所必需的真实的东西。

2) signal + setjump + longjmp. I thought this would work... it's what it's designed for. But I set up my SEGV error handler [in fact I set it up for every signal!] and it's never called during the crash. I can manually test (and succeed) when calling raise(SEGV). But the crashes don't seem to actually call it. My thoughts are that CFM applications do NOT have access to the full BSD signals, only a subset, and that Mach applications are necessary for the Real Thing.

3)MPSetExceptionHandler。无据可查。我试图建立一个处理程序。它编译和运行,但没赶上段错误。

3) MPSetExceptionHandler. Not well documented. I attempted to set a handler. It compiled and ran, but did not catch the segfault.

推荐答案

你确定你没有得到一个SIGBUS而不是一个SIGSEGV?

Are you sure you're not getting a SIGBUS rather then a SIGSEGV?

下面捕获SIGBUS所引起的试图在写入内存位置0:

The below catches SIGBUS as caused by trying to write at memory location 0:

cristi:tmp diciu$ cat test.c

#include <signal.h>

static void sigac(int sig)
{
    printf("sig action here, signal is %d\n", sig);
    exit(1);
}

int main()
{
    (void)signal(SIGSEGV, sigac);
    (void)signal(SIGBUS, sigac);

    printf("Raising\n");
    strcpy(0, "aaksdjkajskd|");
}



cristi:tmp diciu$ ./a.out 
Raising
sig action here, signal is 10

这篇关于异常包装在OSX碳C的应用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆