Most Efficient Replacement for Isbadreadptr

Most efficient replacement for IsBadReadPtr?

a thread-safe solution would be nice

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

just doing a memcpy inside an exception handler

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

--Edit:--

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:

• Know what threads are running in your process
• Know where the threads' stacks are, and how big they are
• Walk down each stack, delberately touching each page of the stack at least once, before you begin to call isBadReadPtr

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

Check if memory is readable or why do it not catches the exception?

Your GetCurrentData() implementation is returning a pointer to a local array that goees out of scope when the function exits, then EventCalled() tries to use that poiner after it is no longer valid. Try this instead:

function GetCurrentData(Address: Pointer): AnsiString; 
var 
  Offset: Integer; 
begin 
  Result := '';
  Offset := 0; 
  repeat 
    try 
      if PByte(Longint(Address) + Offset)^ = #0 then Break;
      Inc(Offset); 
    except 
      Break; 
    end; 
  until False; 
  SetString(Result, PAnsiChar(Address), Offset); 
end; 

procedure EventCalled; 
var 
  TmpAddress: Pointer; 
  StringData: AnsiString; 
begin 
  {$ASMMODE intel} 
  asm 
    mov [TmpAddress], edi 
  end; 
  StringData := GetCurrentData(TmpAddress); 
  IPCClient.SendStringMessage('update:' + StringData); 
  //IPCClient.SendStringMessage('update'); 
end; 

Intel Pin: correctly continuing execution after RECEIVED_ACCESS_FAULT exception

You should always access application memory from your analysis routines using PIN_SafeCopy(), which is declared as follows:

size_t LEVEL_PINCLIENT::PIN_SafeCopy(VOID* dst, const VOID* src, size_t size)

The function returns the number of bytes successfully copied from the source buffer. So you can compare it to size to determine whether it was fully successful or not. PIN_SafeCopyEx() is a similar function that provides additional information in case of failure.

Do I need to call ReleaseBuffer in this context?

Short answer: No.

The longer answer is: Don't call GetBuffer/GetBufferSetLength either. Call GetString instead. It will return a pointer to the immutable sequence of characters. This requires a const_cast as well, i.e.

sInfo.dwTypeData = const_cast<TCHAR*>(strHostLabel.GetString());

This is due to the fact that MENUITEMINFO is used both for setting menu items, as well as reading information back. Since C doesn't allow you to specify transitive constness, the structure is forced to use non-const data members, even when the pointed-to data is never changed. The const_cast is both required as well as safe.

Also note that setting the cch member is not required. As the documentation explains:

[...] cch is ignored when the content of a menu item is set by calling SetMenuItemInfo.

How to check if a pointer is valid in C++?

Memory managers do tend to be closer to the hardware level and may need to make decisions based on the operating system and CPU type they're used on.

In this case you may be able to justify breaking some of the C++ abstract machine rules. For example, just go ahead and compare your pointer with the boundaries of your pool array. Yes, this can go wrong on architectures that use segmented memory or that can form trap pointers, but what else are you going to do?

After that, to validate that you have a proper pointer you can have your allocator write a magic value into the allocation header block, which you can verify in the deallocate function before you start writing into free booleans and free block pointers, etc.

Caliburn Can{Action} not getting updated on Refresh()

You just gave the answer in your question:

NotifyOfPropertyChange(() => CanAddAllToProfile);

That is the appropriate way to tell the binding infrastructure that it should call CanAddAllToProfile and update anything that is binding to that property (such as the button named AddAllToProfile). So if it works, why are you not doing that?

---

Related Topics