CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Question marks in memory window

    While debugging an application I ran into what seems to be a dangling pointer. When I copy the pointer's address into the memory window in VS2008 (while debugging), I see a bunch of question marks instead of normal data - see attached image.
    Does anyone know what that means (i.e. what has happened to the memory)? Am I looking at a section of memory that has been unpaged (if that's the correct term)?

    Name:  VS_memory_window.gif
Views: 4876
Size:  10.0 KB

    Thanks!
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  2. #2
    Join Date
    May 2009
    Location
    Bengaluru, India
    Posts
    460

    Re: Question marks in memory window

    Since it is a dangling pointer it is pointing to some junk memory.

  3. #3
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,675

    Re: Question marks in memory window

    I've never seen this in my own debugging sessions, but I'd interpret that as an address range which has not been assigned any physical memory at all (neither RAM nor page file space). I'm not sure if that's actually what you meant by "unpaged", but I think programs like Process Explorer woud call that "uncommited". This assumption is supported by the fact that the address where the "real" data starts (0x0769E000) is on a 4k boundary, which is the most commonly used memory page size. I don't think that memory has just been paged out (i.e. stored in the page file and then released the physical RAM), because then it would certainly have been paged back in transparently on demand from the debugger.

    Do you get a 0xC000005 thrown for that pointer? Accessing uncommitted addresses is one of the most common reasons for this exception, even when just attempting a read.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  4. #4
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Question marks in memory window

    Quote Originally Posted by vcdebugger View Post
    Since it is a dangling pointer it is pointing to some junk memory.
    Thanks for your response. However, I'm not sure if it is a dangling pointer. I'm trying to figure out what happened to the memory (or pointer). I've never noticed the question marks in the memory window before and was wondering if they have a special meaning.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  5. #5
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Question marks in memory window

    Quote Originally Posted by Eri523 View Post
    I've never seen this in my own debugging sessions, but I'd interpret that as an address range which has not been assigned any physical memory at all (neither RAM nor page file space). I'm not sure if that's actually what you meant by "unpaged", but I think programs like Process Explorer woud call that "uncommited". This assumption is supported by the fact that the address where the "real" data starts (0x0769E000) is on a 4k boundary, which is the most commonly used memory page size. I don't think that memory has just been paged out (i.e. stored in the page file and then released the physical RAM), because then it would certainly have been paged back in transparently on demand from the debugger.

    Do you get a 0xC000005 thrown for that pointer? Accessing uncommitted addresses is one of the most common reasons for this exception, even when just attempting a read.
    Thanks, Eri. Yes, I did get a 0xC000005 exception.

    It turns out the pointer was pointing to deallocated memory. The memory window shows 0xFEEEFEEE repeatedly (special value for deallocated heap memory) just after the deallocation, but later just before the dangling pointer is accessed, the memory window shows the question marks. Perhaps the memory page has been returned to the OS by then.

    If anyone knows for sure what the question marks mean (or can give a reference), I'm still interested.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  6. #6
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Question marks in memory window

    All the process' memory space is virtual. And virtual memory page remains to be virtual one until VirtualAllocEx call instructs VMM to allocate and commit a physical memory page to the address space. So, the question marks indicate uncommitted memory. Reserved or not, don't know, but uncommitted for sure.
    Last edited by Igor Vartanov; January 2nd, 2013 at 09:29 AM.
    Best regards,
    Igor

  7. #7
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Question marks in memory window

    Quote Originally Posted by Igor Vartanov View Post
    All the process' memory space is virtual. And virtual memory page remains to be virtual one until VirtualAllocEx call instructs VMM to allocate and commit a physical memory page to the address space. So, the question marks indicate uncommitted memory. Reserved or not, don't know, but uncommitted for sure.
    Thanks, Igor.
    So, when I'm not calling VirtualAllocEx myself, the question marks could either indicate memory that was never allocated or memory that has been deallocated (and decommitted by the heap allocator).
    If I see the value 0xFEEEFEEE repeatedly, I'm just lucky to know the memory has been deallocated, but hasn't been decommitted by the heap allocator yet.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured