|
Hey guys,
When I'm running my debugger, I am getting a strange problem that keeps occuring. If I click run, the debugger follow throughs the whole source code and gives me an access violation of 0xC0000005. If I do a run to cursor, then I am forced by the debugger to provide the location of CRT0.C. The program runs fine without the debugger, just doesnt output the correct results. Would anyone know the reason for that?
Thanks
Robbie
|
|
|
|
|
capricious_001 wrote: If I click run...
Is that F5 or Ctrl+F5?
capricious_001 wrote: The program runs fine...just doesnt output the correct results.
How can a program run fine but not output the correct results?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
Is that F5 or Ctrl+F5?
With F5 I get an access violation. CTRL+F5 produces no run-time error and the program is executed.
DavidCrow wrote: How can a program run fine but not output the correct results?
It does not fail at run-time, meaning there are no run-time errors, but the results it outputs, say to console, is not whats expected.
|
|
|
|
|
|
SaRath C wrote: check for missing resources.
What do you mean? Resources in the preprocesser directives? The debuggers resources? Or somewhere else?
|
|
|
|
|
there's might have entries in the DoDataExchange function of deleted resources!
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
SaRath C wrote: there's might have entries in the DoDataExchange function of deleted resources!
Hey Sarath,
Do have any good tuts on how to use it, because msdn doesnt provide a good reference and I tried googling it, and the usage of it is vague.
I'm not using MFC, so if there is an alternate way of retreiving the desired output from this function would you know how?
|
|
|
|
|
Hi all,
I created a map file like this :
HANDLE hMap=CreateFileMapping(hFile, NULL, _dwProtect, 0, _dwSize, _strMapName);
but now I need to increase its size and create a new view on it!! does someone know how to to that the right way??
Thank you so much 
|
|
|
|
|
hatemtalbi wrote: but now I need to...create a new view on it!!
To start over, can't you just call UnmapViewOfFile() followed by CloseHandle()?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, I did all that. But when I call mapViewOfFile() the secon time the whole size of the maapped file !!!
|
|
|
|
|
hatemtalbi wrote: But when I call mapViewOfFile() the secon time the whole size of the maapped file !!!
Your sentence is incomplete. What happens when you call MapViewOfFile() the second time?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
for example when I resize the file from 4KB to 8KB, I expect that MapViewOfFile() return a buffer size of 8KB but I get only 4KB !!!
|
|
|
|
|
This is to be expected - that is how file-mapping objects work.
You should use the ZwResizeSection native-API if you want to resize the file-mapping object. Lots of info on google about this.
James
http://www.catch22.net
|
|
|
|
|
Sorry, I typed ZwResizeSection in google but I didn't get any results !!
please could you check the word orthography
thank you
|
|
|
|
|
|
Hi,
I would like to change the standard CTabCtrl to get a little button on the far right side.
The number of tabs should be dynamic, so the control must reserve some space for the button (it shall not draw over the button when there is a high number of tabs). Do I need to write an ownerdraw control or maybe I can reuse CTabCtrl? Thanks for help.
/M
|
|
|
|
|
|
Does this mean I have to write an ownerdraw control to get this functionality?
|
|
|
|
|
Hey,
does someone know how to check if a pointer is valid (was allocated by the application and can be used without problem) or no?
|
|
|
|
|
Have you looked into IsBadCodePtr(), IsBadReadPtr(), IsBadWritePtr(), or IsBadStringPtr()?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
You are asking for trouble if you rely on these APIs to tell if memory is safe to use. For example with heaps when you free a block it doesn't mean the memory is deallocated straight away; it can be marked as free and recycled. This is how heaps work. In short if IsBadReadPtr returns TRUE you know for sure that the memory isn't safe to read; but if it returns FALSE it does ***NOT*** mean that the memory is safe to use - it could be on the heap's free list for example. These API are only meant for debugging purposes and not for memory management in the manner your post alludes to.
Steve
|
|
|
|
|
Stephen Hewitt wrote: These API are only meant for debugging purposes and not for memory management in the manner your post alludes to.
Hence my question. 
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
In Windows you can try IsBadReadPtr, IsBadWritePtr and IsBadStringPtr.
In MFC you can try AfxIsValidAddress and AfxIsValidString.
In case of run-time library, you can try _CrtIsValidPointer, _CrtIsValidHeapPointer and _CrtIsMemoryBlock.
|
|
|
|
|
AfxIsValidAddress worked fine for me.
Thanks a lots
|
|
|
|
|
You are asking for trouble if you rely on these APIs to tell if memory is safe to use. For example with heaps when you free a block it doesn't mean the memory is deallocated straight away; it can be marked as free and recycled. This is how heaps work. For example: if IsBadReadPtr returns TRUE you know for sure that the memory isn't safe to read; but if it returns FALSE it does ***NOT*** mean that the memory is safe to read - it could be on the heap's free list for example.
Most people don't believe when I tell them this. The following code shows this effect in action:
int *pInt = new int;
delete pInt;
ASSERT( AfxIsValidAddress(pInt, sizeof(int)) );
If this practice was safe the ASSERT should fire: it doesn't. The memory is being cached in the heap but it is definitely ***NOT*** safe to use it. DO NOT USE THIS TECHNIQUE!
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
