代码之家 › 专栏 › 技术社区 › sud03r

使用C动态加载例程时出现问题

drmaa dlsym sungridengine shared-libraries c++

0

sud03r · 技术社区 · 16 年前

我有一个应用程序,包括用C++编写的不同模块。
其中一个模块用于处理Sungrid引擎上的分布式任务。它使用DRMAA API 提交和监视网格作业。如果客户端不支持网格,则应使用本地计算机。

api libdrmaa.so的共享对象在编译时链接并在运行时加载。
如果使用我的应用程序的客户机有这个“,那么”一切都很好,但是如果客户机没有这个, 应用程序退出时无法加载共享库。
为了避免这种情况,我将API调用替换为使用dlsym()和dlopen()获得的函数指针。如果对dlopen的调用没有成功并且我的目标实现了,那么现在我可以使用本地机器而不是网格。
现在的问题是,应用程序现在成功地运行在小的测试用例上,但是对于大的测试用例,它会抛出分段错误,同时使用动态加载的相同代码也会正常工作。

使用dlsym()和dlopen()时是否缺少某些内容?
有没有其他方法来实现相同的目标?

任何帮助都将不胜感激。

桑克斯

3 回复 | 直到 13 年前

1

3

Jonathan Leffler 16 年前

它不太可能是通过 dlsym() -在这个意义上,动态负载使它成为SEG故障。

它可能正在做的是暴露一个单独的问题,可能是通过移动东西。这可能意味着一个杂散的(未初始化的)指针指向静态链接案例中“合法”的某个地方,但动态链接案例中的某个地方——而其他地方触发了SEG故障。事实上,从长远来看,这对你是一个好处——它表明有一个问题,否则很长一段时间内可能不会被发现。

我认为这是特别可能的,因为您提到它发生在较大的测试中,而不是小的测试中。

2

1

alanc 13 年前

正如JonathanLeffler所说,这个问题很可能存在于您直接使用API的情况中;它还没有导致崩溃。

当你得到一个 SIGSEGV 应该分析产生的核心转储(或者直接在调试器下运行应用程序),并查看哪里它坠毁了。我敢打赌0.02美元它会在里面的某个地方坠毁。 malloc 或 free 在这种情况下,问题很明显是旧堆损坏,有许多堆检查器工具可帮助您捕获它。Solaris提供 watchmalloc 这是一个良好的开端。

3

0

Loki Astari 16 年前

如果要在外部“c”函数中引发异常,则应用程序必须退出。这是因为cABI没有传播异常的工具。

为了在使用DLL(或共享LIBS)时对此进行反击,通常您有一个返回C++对象的C函数。然后剩下的交互是从DLL返回的C++对象。

这种模式表明(我强调说)一个类似工厂的对象,因此您的DLL应该有一个外部的“C”函数,它返回一个空隙*,您可以将它重新解释为Clas& lt;&返回到C++工厂对象中。