指针以某种方式失效,这会导致访问冲突

发布于 2024-12-29 07:13:48 字数 791 浏览 2 评论 0原文

开发环境为VS2010,语言为C#(GUI)和C++(Sim Engine)混合,针对32位Windows进行编译。我们测试过的每个 Windows 版本都会出现异常,包括 32 位 XP、32 位 Vista、32 位 7 和 64 位 7。

我对此完全不知所措。由于程序的性质(基于事件的模拟),在我们实际尝试访问它并获取 AVE 之前,指针会在某个未知时间点失效。

我所知道的是,它正在以一种非常特殊的方式失效,我希望有人可能知道是什么导致了这种情况。当AVE发生时,它试图使用的指针已更改为:

(original) - ((size * 2) - 1)  

其中original是指针指向的原始地址,size是被指向的对象。

例如,其中一个访问冲突发生在应该指向0x58E0的指针上,而该对象的大小为0x70。它没有指向 0x58E0,而是指向 0x5801,即 0x58E0 - ((0x70 * 2) - 1)。同样的事情也会发生在另一个不同类型和大小的对象上,因此这似乎是一种非常具体的关系。

编辑:在上面我不是谈论在代码中进行指针算术,我只是展示指针应该是什么之间的数学关系当我们引用它并得到访问冲突异常时。希望事情能澄清。

编辑 2:我刚刚意识到,据我所知,我们只在 std 向量成员的对象上看到过这个问题。我们的向量实现中是否有什么地方搞砸了,从而导致了这种行为?

Dev Environment is VS2010 and language is mixed C# (GUI) and C++ (Sim Engine), compiling for 32-bit Windows. The exceptions occur on every version of Windows we have tested with including 32-bit XP, 32-bit Vista, 32-bit 7, and 64-bit 7.

I am completely at a loss with this one. Because of the nature of the program (events-based simulation), the pointer is invalidated at some unknown point in time before we actually try to access it and get the AVE.

What I do know is that it is being invalidated in a very particular way, and I'm hoping someone out there might have an idea as to what could cause this. When the AVE happens, the pointer that it was trying to use has been changed to:

(original) - ((size * 2) - 1)  

Where original is the original address pointed to by the pointer, and size is the size of the object being pointed to.

For example, one of the access violations occurred on a pointer that should have pointed to 0x58E0, and the object had a size of 0x70. Instead of pointing to 0x58E0, it pointed to 0x5801 which is 0x58E0 - ((0x70 * 2) - 1). The same thing happens with another object of a different type and size, so it seems to be a very specific relationship.

Edit: In the above I am not talking about doing pointer arithmetic in the code, I am only showing the mathematical relationship between what the pointer should be and what it ends up as when we reference it and get the Access Violation Exception. Hope that clears things up.

Edit 2: I just realized that as far as I can remember, we have only seen this problem with objects that are members of a std vector. Is there something that we could have screwed up in our vector implementation that could have caused this behavior?

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

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

发布评论

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

评论(2

倚栏听风 2025-01-05 07:13:48

腐败的本质表明有人在使用 realloc 时搞砸了。

The nature of the corruption suggests someone messed up using realloc.

深海不蓝 2025-01-05 07:13:48

我刚刚意识到,据我所知,我们只在 std 向量成员的对象上看到过这个问题。我们的向量实现中是否有什么地方搞砸了,从而导致了这种行为?

这不是向量实现的问题,而是你如何使用它的问题。

vector 每当其容量增加时,它肯定会使迭代器和指向现有对象的指针失效。您看到的特殊数学关系将与您的特定实现的增长模式相关。

解决方案是在向量大小发生变化时不要保留指向向量内容的指针。您可以保留指向向量的指针和索引,这将继续有效。

I just realized that as far as I can remember, we have only seen this problem with objects that are members of a std vector. Is there something that we could have screwed up in our vector implementation that could have caused this behavior?

It's not a problem with the vector implementation, it's a problem with how you use it.

vector most certainly invalidates iterators and pointers to existing objects whenever it grows its capacity. The peculiar mathematical relationship you're seeing is going to be related to the growth pattern of your particular implementation.

The solution is not to keep pointer to vector contents while the size of the vector is changing. You could keep a pointer to the vector and an index, that would continue to be valid.

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