最有效的替换IsBadReadPtr? [英] Most efficient replacement for IsBadReadPtr?

查看:3243
本文介绍了最有效的替换IsBadReadPtr?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一些Visual C ++代码接收指向缓冲区的指针,需要由我的代码处理的数据和缓冲区的长度。由于我的控制之外的错误,有时这个指针进入我的代码未初始化或不适合读取(即,当我尝试访问缓冲区中的数据时会导致崩溃。)

I have some Visual C++ code that receives a pointer to a buffer with data that needs to be processed by my code and the length of that buffer. Due to a bug outside my control, sometimes this pointer comes into my code uninitialized or otherwise unsuitable for reading (i.e. it causes a crash when I try to access the data in the buffer.)

所以,我需要在使用它之前验证这个指针。我不想使用IsBadReadPtr或IsBadWritePtr,因为每个人都同意他们是buggy。 (Google的例子)。他们也不是线程安全的 - 这可能不是一个关注在这种情况下,虽然线程安全的解决方案是很好的。

So, I need to verify this pointer before I use it. I don't want to use IsBadReadPtr or IsBadWritePtr because everyone agrees that they're buggy. (Google them for examples.) They're also not thread-safe -- that's probably not a concern in this case, though a thread-safe solution would be nice.

我已经看到了通过使用VirtualQuery或者通过在异常处理程序内部执行memcpy来实现这一点的建议。然而,需要进行此检查的代码是时间敏感的,因此我需要最有效的检查,也是100%有效。任何想法将不胜感激。

I've seen suggestions on the net of accomplishing this by using VirtualQuery, or by just doing a memcpy inside an exception handler. However, the code where this check needs to be done is time sensitive so I need the most efficient check possible that is also 100% effective. Any ideas would be appreciated.

只是为了清楚:我知道最好的做法是只读坏指针,让它引起异常,然后跟踪回到源并修复实际问题。但是,在这种情况下,错误的指针来自我无法控制的Microsoft代码,因此我必须验证它们。

Just to be clear: I know that the best practice would be to just read the bad pointer, let it cause an exception, then trace that back to the source and fix the actual problem. However, in this case the bad pointers are coming from Microsoft code that I don't have control over so I have to verify them.

还要注意,我不注意所指向的数据是否有效。我的代码正在寻找特定的数据模式,如果没有找到它们将忽略数据。我只是试图防止在这个数据上运行memcpy时发生的崩溃,并且在memcpy尝试时处理异常将需要更改我的代码中的十几个地方(但如果我有像IsBadReadPtr调用我只会必须在一个地方更改代码)。

Note also that I don't care if the data pointed at is valid. My code is looking for specific data patterns and will ignore the data if it doesn't find them. I'm just trying to prevent the crash that occurs when running memcpy on this data, and handling the exception at the point memcpy is attempted would require changing a dozen places in my code (but if I had something like IsBadReadPtr to call I would only have to change code in one place).

推荐答案


/ p>

a thread-safe solution would be nice

我猜想只有IsBadWritePtr不是线程安全的。

I'm guessing it's only IsBadWritePtr that isn't thread-safe.

这是有效的IsBadReadPtr在做什么...

只是在异常处理程序内部执行memcpy

just doing a memcpy inside an exception handler

如果你在你的代码中,那么你的代码会有与IsBadReadPtr实现相同的错误: http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

This is effectively what IsBadReadPtr is doing ... and if you did it in your code, then your code would have the same bug as the IsBadReadPtr implementation: http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

- 编辑: -

我读过的IsBadReadPtr的唯一问题是坏指针可能指向(因此你可能会意外触摸)堆栈的保护页。也许你可以避免这个问题(因此安全地使用IsBadReadPtr):

The only problem with IsBadReadPtr that I've read about is that the bad pointer might be pointing to (and so you might accidentally touch) a stack's guard page. Perhaps you could avoid this problem (and therefore use IsBadReadPtr safely), by:


  • 知道你的进程中运行的线程

  • 知道线程堆栈在哪里,以及它们有多大。

  • 沿着每个堆栈走,至少一次触摸堆栈的每一页,开始之前调用isBadReadPtr

此外,与上述URL相关联的一些注释也建议使用VirtualQuery。

Also, the some of the comments associated with the URL above also suggest using VirtualQuery.

这篇关于最有效的替换IsBadReadPtr?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆