隔离 Mono 下的非托管崩溃
我们在 Linux 下有一个 Mono 应用程序，可以对一堆文件进行图像处理。
为此，我们（除其他外）使用 System.Drawing，并且在大多数情况下它对我们很有帮助。然而，有时我们会遇到使应用程序崩溃的图像 - 这是本机调用中的崩溃，并且这不受 try catch 的影响。简单来说，类似的调用
System.Drawing.Image.FromFile(imagePath);
会导致崩溃。错误消息看起来像这样：
at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipLoadImageFromFile (string,intptr&) <0xffffffff>
这会立即拉动整个应用程序。
我们遇到过一些发生这种情况的实例 - 损坏的 GIF 文件、TIFF 文件中意外的标头 - 仅举几例。由于我们无法控制图像的来源，因此我们只需要处理可能的崩溃。
问题：我想隔离我们在不受信任的文件上使用 GDI+（通过 System.Drawing）的地方，以便它可以愉快地崩溃而不会杀死整个应用程序。
我已经通过使用单独的应用程序域尝试过此操作，但我无法阻止崩溃。很可能我做错了！
<子> 一些细节：openSUSE 11.4（x86_64），Mono版本2.10.2，libgdiplus0（包）2.10-30.2，libtiff3（包）3.9.4-3.7.1
请注意，我们遇到的具体问题已得到及时修复 - 请参阅下面的评论。但问题仍然存在。
我本来希望以某种方式隔离程序的一部分，这样它就不会拉低整个程序 - 但我担心唯一的答案是调用外部进程，如下面的答案中所述。我将保持原样一段时间，然后接受该答案！
We have a Mono application under Linux that does image processing on a bunch of files.
For this we (among other things) use System.Drawing, and for the most part it serves us well. Occasionally however, we encounter an image that crashes the application - it is a crash in a native call, and this is immune to try catch. Simplified, a call like
System.Drawing.Image.FromFile(imagePath);
will cause a crash. The error message looks something like this:
at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipLoadImageFromFile (string,intptr&) <0xffffffff>
This pulls the whole application down instantly.
We have encountered a few instances that this happens - corrupt GIF files, unexpected headers in TIFF files - to name a few. As we don't have control over the source of the images, we will just have to deal with possible crashes.
The question: I would like to isolate the places where we use GDI+ (through System.Drawing) on untrusted files so that it can happily crash without killing the whole application.
I have attempted this through using separate application domains, but I just can't stop the crashes. It is probable that I am doing it wrong!
Some detail: openSUSE 11.4 (x86_64), Mono version 2.10.2, libgdiplus0 (package) 2.10-30.2, libtiff3 (package) 3.9.4-3.7.1
Please note that the specific issues we experienced was promptly fixed - see comments below. The question still remains though.
I would have liked to somehow isolate a part of the program so that it does not pull the whole thing down - but I fear the only answer is to call a external process as noted in the answer below. I'll leave this as is for a while and then accept that answer!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，这里有一些天真，因为我对 Linux 不太了解……AppDomains（无论如何在 Windows 中）驻留在同一个进程中。尝试使用命令行或 IPC 之类的某种通信机制将有问题的代码分离到另一个进程中，这样如果崩溃，它不会导致主进程崩溃，而只会导致子进程崩溃。
尽管我过去从未遇到过导致问题的无法捕获的异常，但听起来主进程正在被终止，这是您所说的尝试过的 AppDomain 想法之下的一层。
必要时翻译成 Linuxese...抱歉我不能说得更具体。
Ok, with some measure of naivety here because I don't know much about Linux... AppDomains (in Windows anyway) reside in the same process. Try separating out the problematic code into another process, using command lines or some communication mechanism like IPC so that if it crashes, it doesn't bring down the main process, just the child.
Although I've never had an uncatchable exception causing my problems in the past, it sounds like the main process is being killed, which is a layer below the AppDomain idea you said you tried.
Translate to Linuxese where necessary... sorry I can't be more specific.