Prev: ml.exe
Next: beginner asm, where next?
From: "//o//annabee Free" " on 23 Jan 2007 21:31
P� Tue, 23 Jan 2007 18:16:17 +0100, skrev David Jones <ncic(a)tadmas.com>:

> It's a red herring.

Maybe.

> What does any of this have to do with ascertaining pointer validity?
> The inability to ascertain pointer validity with 100% correctness has
> nothing to do with bugs in the implementation -- it's inherent to the
> system itself.
>
> You might think you could do better, but if Windows presented you a
> strongly-typed mm with strict control so it _could_ ascertain this,
> you'd complain about a lack of flexibility.

Not if it would be fast enough that there would be no need to complain. It
could manage all this itself, and present the same interface as now, as
long as it would be able to account for the memory when asked to do so.

>> > All that has to happen is an
>> > application writing their own memory manager <grin> where a pointer
>> > could point to OS-allocated memory (the custom-mm heap) but not
>> custom-
>> > mm-allocated memory, thus making the pointer invalid.
>>
>> Sorry. I dont comprehend this paragraph.
>
> And you wrote your own memory manager...? Where did you get the memory
> to manage?

I paid for it. :)

> The OS gives you a chunk (either through you asking
> explicitly for a chunk through a XxxxAlloc-type function or implicitly
> by reserving space in your executable), and you partition it as needed.

And todo that sensibly I have to uncover the bugs in the OS mm, and write
around them.
For each version of windows. And I have no way of knowing, except through
experience with running in diffrent environments, wheather the changes I
made, are valid across all configurations. All bets are off. I cannot rely
on the spesification, because the OS makers are breaking the
spesifications with every new version of the os.

> So what happens when a pointer falls in a block allocated by one mm and
> not the other? Who can determine if it's *VALID*? Only the mm that
> allocated it, so any mm-centric view is doomed to fail (just switch the
> roles).

Theres really only one ultimate mm, that is windows. It should be able to
answer the question of "sBadXxxPtr()" without causeing applications to
break from it. And it should be able todo this in a very fast linear time.

>
> David

From: David Jones on 24 Jan 2007 01:08
//\\o//\\annabee <Free" <Wannabee(a)wannabee.org> wrote...
> På Tue, 23 Jan 2007 18:16:17 +0100, skrev David Jones <ncic(a)tadmas.com>:
>
> > So what happens when a pointer falls in a block allocated by one mm and
> > not the other? Who can determine if it's *VALID*? Only the mm that
> > allocated it, so any mm-centric view is doomed to fail (just switch the
> > roles).
>
> Theres really only one ultimate mm, that is windows. It should be able to
> answer the question of "sBadXxxPtr()" without causeing applications to
> break from it. And it should be able todo this in a very fast linear time..

(1) You CAN determine if memory is readable or writable without using
IsBadXxxPtr -- use VirtualQuery instead. Yes, it is slower than
IsBadXxxPtr, but you avoid the bugs.

Like many things in Windows, it still exists because taking it out would
break compatibility with existing programs, even if it's flawed. It's
the same problem as the overhead on the GlobalAlloc functions --
Microsoft maintains API compatibility going back to very old versions of
Windows.

(2) VirtualQuery is relatively slow because it does a transition to
kernel mode. (Why? VirtualQuery is really a wrapper around
VirtualQueryEx, which can get memory information from other processes.
You don't really want to map that data from other processes into every
process's address space.)

On my machine, VirtualQuery is about 25 times as slow as calling
IsBadXxxPtr on a single DWORD. When you consider the minimalist
implementation of IsBadXxxPtr, that's not too bad, IMHO. On page-sized
chunks of memory (64K), it's only about 3 times as slow for IsBadReadPtr
and actually 25% faster than IsBadWritePtr.

On my machine (1.7 GHz), VirtualQuery takes about 0.75us per call on
average for 64K memory blocks. Is that too slow for practical use?
Moreover, are you really going to need to check if a pointer points to
allocated memory in a tight loop where performance would be a factor?
(This is kind of a trick question in that, if performance were a factor,
you wouldn't be checking in the first place.)

(3) Determining whether memory is readable or writable still doesn't
determine if it's VALID for a particular use. You keep glossing over
this point, but it's the clincher -- these functions are not only
broken, but they wouldn't really answer the question about validity even
if they had no harmful side effects. It doesn't matter how fast they
are. :)

David
First  |  Prev  | 
Pages: 1 2 3 4
Prev: ml.exe
Next: beginner asm, where next?