【问题标题】:Isolating unmanaged crashes under Mono在 Mono 下隔离非托管崩溃
【发布时间】:2011-12-16 11:16:42
【问题描述】:

我们在 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 (package) 2.10-30.2, libtiff3 (package) 3.9.4-3.7.1


请注意,我们遇到的具体问题已及时修复 - 请参阅下面的 cmets。问题仍然存在。

我本来希望以某种方式隔离程序的一部分,这样它就不会把整个事情拖垮——但我担心唯一的答案是调用一个外部进程,如下面的答案所述。我会保留一段时间,然后接受这个答案!

【问题讨论】:

  • 我建议为导致崩溃的图像提交错误 (bugzilla.xamarin.com),以便修复问题。由于图像解析历来是安全问题的根源,因此最好将错误设为 Xamarin 私有,这样您就不会泄露可能的安全问题。
  • 对,登录为 bugzilla.xamarin.com/show_bug.cgi?id=1752bugzilla.xamarin.com/show_bug.cgi?id=1753 最后,我们尽可能避开了 System.Drawing,并依赖于 Mono 下的 Gdk,到目前为止,它似乎更加强大。
  • @FPC 这两个问题现在都已修复。谢谢!
  • 太棒了! 印象深刻。谢谢。

标签: c# .net mono system.drawing


【解决方案1】:

好吧,这里有点天真,因为我对 Linux 了解不多…… AppDomains(无论如何在 Windows 中)驻留在同一个进程中。尝试使用命令行或诸如 IPC 之类的某种通信机制将有问题的代码分离到另一个进程中,这样如果它崩溃,它就不会关闭主进程,而只会关闭子进程。

虽然我过去从未遇到过导致我的问题的无法捕获的异常,但听起来主进程正在被杀死,这是您所说的您尝试过的 AppDomain 想法之下的一层。

必要时翻译成 Linuxese...抱歉,我不能说得更具体。

【讨论】:

  • 好建议——我把“炮轰”作为最后的手段! IPC 听起来像是打开了一个痛苦的世界——至少让它运转良好。但我想我可能不得不屈服了。感谢您的回答!
  • IPC 实际上相当简单,它在具有旧的 .NET Remoting 基础架构的 Windows 中。就我个人而言,我只是命令行它并等待 exe 的退出代码,这是你可以很好地控制的。
  • 问题是速度是一个要求。对数千个图像文件进行炮击将是低效的。 IPC - 或类似的东西似乎是最好的选择 - 现在谷歌搜索
  • 在这种情况下,我会检查库本身的使用情况并尝试替换它。获取一个不会导致天启的库,然后您可以将所有代码保存在一个 exe 中。 AForge.NET 非常好,虽然我不确定 Mono 有什么。
  • gdiplus 实现使用(其他)本机库进行图像加载。这些库很常见,因此任何其他也提供图像解析(在 linux 上)的托管库都可能使用相同的本机库(除非它们完全在托管代码中执行)。我的建议是启动一个外部进程并在图像导致崩溃时重新启动它,并且只有在这对您来说太慢时才尝试找到一种更安全的方式来执行它。
猜你喜欢
  • 1970-01-01
  • 2010-10-18
  • 2023-03-29
  • 1970-01-01
  • 2017-03-07
  • 2014-03-10
  • 2010-09-20
  • 1970-01-01
  • 2013-02-01
相关资源
最近更新 更多