如何处理加载错误的共享库版本的情况

时间:2018-04-20 20:49:39

标签: c++ linux shared-libraries embedded-linux

我面临着奇怪的情况。我的引擎应该调用另一个库的某些功能。问题是如果我在系统中有错误的(不兼容的)库包版本,引擎将停止工作,没有任何异常或Linux信号。基本上,引擎正在处理基本的Linux信号作为分段故障等。这些信号不会出现。我的程序看起来像:

try {
    interface->somefunctioncall(...);
} catch(...) {
    ;
}

interface-> somefunctioncall(...)调用另一个包中的另一个共享库。如果包有错误的版本,此调用将导致引擎崩溃,并且Linux系统中没有关于它的信息。我只想以某种方式处理这种情况并将一些信息存储到日志中。无论发生什么。引擎可能崩溃。但是我希望在日志中存储信息,为什么引擎崩溃了。 另一个不错的提示可能是,如果我能在运行时处理这种情况并且引擎可以继续。 确保我在嵌入式Linux上开发,使用第三方软件的可能性有限。 请不要提示:

if (packageversion != expectedversion) {
    do_not_do_call_and_log_the_problem();
} else {
    interface->somefunctioncall(...);
}

非常感谢提示。 : - )

1 个答案:

答案 0 :(得分:0)

你能看到CPU在做什么吗?如果它与100%挂钩,那可能意味着你处于无限循环中,这可以解释缺乏崩溃的原因。 如果是无限循环,您可以做的一件事是在拨打电话之前设置闹钟并在之后取消。

alarm( 5 ); // 5 seconds, make it long enough to be certain that somefunctioncall should have returned
interface->somefunctioncall(...);
alarm( 0 ); // to cancel the alarm

然后,无论您在代码中处理信号的哪个位置,都要处理SIGALRM信号。如果你收到SIGALRM,那么“受保护”的呼叫可能是无限循环,你可以在记录你想要的任何内容后中止该程序。

我应该补充一点,这确实不是最佳解决方案,除非您对系统上的软件包版本没有管理控制权。这是一个解决方案,解决了一个真正应该在其他地方解决的问题。

这不是最佳的一个具体原因是它会产生潜在的竞争条件。这可以通过使警报时间比呼叫应该花费的时间长得多来减轻。然而,这会产生新的潜在问题(并使代码复杂化),以“修复”应该在其他地方修复的其他问题。