函数调用跳转到错误的函数

发布于 2024-07-09 23:02:13 字数 276 浏览 11 评论 0原文

我正在 vs2008 中编译一个 c++ 静态库,在解决方案中我还有一个使用该库的启动项目,并且工作正常。

但是,当在另一个解决方案中使用该库时,我遇到运行时检查失败。 “ESP 的值未在函数调用中正确保存” 单步执行代码时,我注意到函数 foo() 跳转到了 bar(),而不是在崩溃之前。 所讨论的函数只是常规函数,没有函数指针。

任何人都知道可能会发生什么,以及为什么在使用同一解决方案中的库时它会起作用?

编辑:函数(方法)是类的一部分,如果有帮助的话。

I am compiling a c++ static library in vs2008, and in the solution i also have a startup project that uses the lib, and that works fine.

But when using the lib in another solution i get an run-time check failure.
"The value of ESP was not properly saved across a functioncall"
Stepping through the code i noticed a function foo() jumping to bar() instead right before the crash. The functions in question are just regular functions and no function pointers.

Anyone has any clue what might be going on, and why it works when using the lib's from the same solution?

edit: the functions (methods) are part of a class, if that helps.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

夏见 2024-07-16 23:02:13

请原谅我在这里指出明显的出血问题,但是......当对象(.o)和头文件(.h)不同步时,我以前已经多次看到这种事情发生了。 特别是对于虚拟方法。

考虑: 目标文件是用标头编译的:

class Foo { virtual void f(); };

但随后标头更改为:

class Foo { virtual void g(); virtual void f(); };

对于下一个目标文件,编译器关于 f() 在类的 vtable 中的位置的假设是不正确的。

通常,只需重新编译世界(一切!)就会有所帮助。

Forgive me for stating the bleeding obvious here, but... I've seen this sort of thing happen many times before when object (.o) and header (.h) files get out of sync. Especially with respect to virtual methods.

Consider: The object file is compiled with header:

class Foo { virtual void f(); };

But then the header gets changed to:

class Foo { virtual void g(); virtual void f(); };

And for the next object file, the compiler's assumptions about where f() is located in the class's vtable are incorrect.

Oftentimes simply recompiling the world (everything!) will help.

韶华倾负 2024-07-16 23:02:13

这很可能是由于调用约定不兼容,库和调用者对堆栈布局有不同的想法。

有关详细信息,请参阅 MSDN

This is most probably due to incompatible calling conventions, where the library and the caller have different ideas about stack layout.

Take a look at MSDN for more info.

赢得她心 2024-07-16 23:02:13
  • 请确保您尚未选择
    在你的项目中的旧版本
    图书馆,即(正如亚当提到的)
    您选择了较旧的调试
    版本而不是当前版本
    版本,反之亦然。

  • 您可能需要重建。

  • 还要注意宏可能会出现的条件编译
    #define 或 #undef'd 在某些时候(另一个解决方案可能有一些
    宏或预计的#defines)。 一些
    有时删除可能会有所帮助
    你的.lib .obj,并预编译
    标头缓存与重建。

  • 您的 IDE 中极有可能出现问题
    或项目配置,您可以在其中
    可能需要重新创建您的项目
    从头开始。

  • 我对MS VC不太熟悉,你能添加库的项目吗
    来自其他解决方案的文件? 为了
    例如,在 Borland C++ Builder 中,您
    可以定义项目组和
    构建/制作多个项目,我
    始终将项目放在
    我在程序中使用的库
    项目组所以一切都得到
    我构建时是最新的。

  • Make sure that you haven't selected
    in your project an old version of a
    library, I.e. (as Adam mentioned)
    you have selected an older debug
    version instead of a current release
    version or vica versa.

  • You might need to rebuild.

  • Also watch out for conditional compilation where a macro might get
    #defined or #undef'd at some point (The other solution may have some
    macros or projected #defines). Some
    times it might be helpful to delete
    your .lib .obj, and precompiled
    header caches with rebuild.

  • There is a remote possibility that something is messed up in your IDE
    or project configuration, where you
    might need to recreate you project
    from scratch.

  • I am not too familiar with MS VC, can you add the library's project
    file from the other solution? For
    example, in Borland C++ Builder you
    can define project groups and
    build/make multiple projects, I
    always put the projects for the
    libraries I use in my program
    project group so everything gets
    up-to-date when I build.

毁虫ゝ 2024-07-16 23:02:13

确保您在调试模式而不是发布模式下进行编译。 如果您尝试在发布模式下调试程序,则由于优化,从调试器返回的数据将是垃圾。

Make sure you're compiling in Debug mode and not Release mode. If you attempt to debug a program in Release mode, the data you get back from the debugger will be garbage due to optimizations.

寄人书 2024-07-16 23:02:13

我记得当二进制文件的结构成员对齐(/Zp 编译器开关)不同时看到过这样的事情。 你也可以检查一下。

通过 #pragma pack 设置它而不是通过项目设置应该更安全。

I remember seeing such things when the struct member alignment (/Zp compiler switch) of the binaries was different. You could check that, too.

Setting it via #pragma pack rather than via project settings should be safer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文