“检测到 PInvokeStackImbalance”来自 HDFDotNet 1.8.7
我一直在尝试更新到最新的 HDF5DotNet 包装器 (1.8.7)，但收到以下警告（从 VS2010 在调试模式下运行时）：
检测到 PInvokeStackImbalance 消息：对 PInvoke 函数“HDF5DotNet!::H5Fopen”的调用使堆栈不平衡。 这可能是因为托管 PInvoke 签名与非托管目标签名不匹配。 检查 PInvoke 签名的调用约定和参数是否与目标非托管签名匹配。
我正在使用预编译的二进制文件（.NET Framework 4.0 32 位的 HDF5DotNet 程序集），但从源代码编译时得到了相同的结果。
奇怪的是，当执行在非调试模式下调用 HDF5DotNet 包装器的应用程序时，我没有看到任何问题。我确实注意到，在 1.8.6 和 1.8.7 之间，所有调用约定都从 Cdecl 切换到 StdCall。这可能是导致这个的原因吗？我见过其他论坛说 CallingConvention 应该是 Cdecl...
谢谢！
I have been attempting to update to the latest HDF5DotNet wrappers (1.8.7) and am getting the following warnings (when running in DEBUG mode from VS2010):
PInvokeStackImbalance was detected
Message: A call to PInvoke function 'HDF5DotNet!::H5Fopen' has unbalanced the stack.
This is likely because the managed PInvoke signature does not match the unmanaged target signature.
Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.
I am using the pre-compiled binaries (HDF5DotNet assembly for .NET Framework 4.0 32-bit), but got the same result when I compiled from source.
Strangely, when executing my application that calls the HDF5DotNet wrappers in non-DEBUG mode, I see no problems. I did notice that between 1.8.6 and 1.8.7 all the calling conventions were switched from Cdecl to StdCall. Could this be causing this? I've seen other forums saying the CallingConvention should BE Cdecl...
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，将
stdcall函数作为cdecl调用或相反会导致堆栈不平衡。这些约定之间的主要区别在于，对于cdecl，调用者负责从堆栈中删除参数，而对于stdcall，被调用者负责。我想在发布模式下你也有同样的错误。但您不会收到错误，因为某些运行时检查被禁用。在大多数情况下，如果使用错误的调用约定，本机程序会崩溃，但 .net 互操作代码似乎具有更强大的堆栈处理功能，可以掩盖此问题。
Yes, calling a
stdcallfunction ascdeclor the other way round causes a stack imbalance. The main difference between these conventions is that withcdeclthe caller is responsible for removing the arguments from the stack, with stdcall the callee is responsible.I guess in release mode you have the same bug. But you don't get the error because some runtime checks are disabled. A native program would crash in most cases where you use the wrong calling convention, but it seems like the .net interop code has a more robust stack handling that masks this problem.