-
January 2nd, 2013, 06:32 AM
#1
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)?
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
-
January 2nd, 2013, 07:07 AM
#2
Re: Question marks in memory window
Since it is a dangling pointer it is pointing to some junk memory.
-
January 2nd, 2013, 07:54 AM
#3
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.
-
January 2nd, 2013, 08:50 AM
#4
Re: Question marks in memory window
Originally Posted by vcdebugger
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
-
January 2nd, 2013, 09:12 AM
#5
Re: Question marks in memory window
Originally Posted by Eri523
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
-
January 2nd, 2013, 09:26 AM
#6
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
-
January 2nd, 2013, 10:57 AM
#7
Re: Question marks in memory window
Originally Posted by Igor Vartanov
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|