Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


Subjectweird c++ destructor behaviour Reply to this message
Posted byTerry Bogard
Posted on01/27/04 12:25 PM



I'm using VC++ 6.0 under Windows XP.

I'm coding the functionalities of a very basic POP3 client. I have all the job made by a "POP3" class which cares about the network connection, the parsing of the server's responses and the storage of messages.

Everything seems to be working fine, except the destructor: whenever I try to free the memory allocated for the arrays of chars containing the messages, a debug window with three buttons pops up. It's the old "continue, abort, debug" window, except that it's blank: no text on it.

I have checked everywhere else in my code to make sure no variable still points to that memory area, and I've followed a step by step debug to see what's wrong, but I wasn't able to understand what is the problem with those delete's.

For every delete, the debug console reports something like: "memory check error at 0x00348514 = 0x00, should be 0xFD" which makes little sense to me: why does the debugger check memory values while I am deallocating memory? What is it looking for, exactly?

Also, this problem occurs only with debug builds: release builds report no errors of sort, and the program terminates gracefully.

If anybody has a clue about what goes on exactly, I'd appreciate that.

I haven't posted source code here because the destructors contains just loops of delete's, but it's no big secret, I even thought to make it available online as public domain once polished, so feel free to ask if you think it's useful.

Thanks in advance.




SubjectRe: weird c destructor behaviour new Reply to this message
Posted byfinaldave
Posted on01/27/04 06:13 PM



> I'm using VC 6.0 under Windows XP.
>
> I'm coding the functionalities of a very basic POP3 client. I have all the job
> made by a "POP3" class which cares about the network connection, the parsing of
> the server's responses and the storage of messages.
>
> Everything seems to be working fine, except the destructor: whenever I try to
> free the memory allocated for the arrays of chars containing the messages, a
> debug window with three buttons pops up. It's the old "continue, abort, debug"
> window, except that it's blank: no text on it.
>
> I have checked everywhere else in my code to make sure no variable still points
> to that memory area, and I've followed a step by step debug to see what's wrong,
> but I wasn't able to understand what is the problem with those delete's.
>
> For every delete, the debug console reports something like: "memory check error
> at 0x00348514 = 0x00, should be 0xFD" which makes little sense to me: why does
> the debugger check memory values while I am deallocating memory? What is it
> looking for, exactly?

good ol' heap corruptions, the daddy of all bastard bugs!

>
> Also, this problem occurs only with debug builds: release builds report no
> errors of sort, and the program terminates gracefully.
>
> If anybody has a clue about what goes on exactly, I'd appreciate that.
>
> I haven't posted source code here because the destructors contains just loops of
> delete's, but it's no big secret, I even thought to make it available online as
> public domain once polished, so feel free to ask if you think it's useful.
>
> Thanks in advance.
>
>

Sounds like you are corrupting the heap. Check out crtdbg.h for lots of nice heap corruption and memory leak tracking tools.

Ah programming for Win32 is so easy, so many helpful tools at your disposal :P



You learn something old everyday...



SubjectRe: weird c destructor behaviour new Reply to this message
Posted bysmf
Posted on01/28/04 03:18 AM



yeah, sounds like the old running off the end of an array problem....

smf





SubjectRe: weird c++ destructor behaviour new Reply to this message
Posted byElSemi
Posted on01/28/04 04:26 AM



hmm, 0x00 at the end of an allocated memory, it's just a guess, but maybe you are allocating n bytes to copy a n chars long string, but you really need n+1 bytes due to the \0 at the end.

> I'm using VC++ 6.0 under Windows XP.
>
> I'm coding the functionalities of a very basic POP3 client. I have all the job
> made by a "POP3" class which cares about the network connection, the parsing of
> the server's responses and the storage of messages.
>
> Everything seems to be working fine, except the destructor: whenever I try to
> free the memory allocated for the arrays of chars containing the messages, a
> debug window with three buttons pops up. It's the old "continue, abort, debug"
> window, except that it's blank: no text on it.
>
> I have checked everywhere else in my code to make sure no variable still points
> to that memory area, and I've followed a step by step debug to see what's wrong,
> but I wasn't able to understand what is the problem with those delete's.
>
> For every delete, the debug console reports something like: "memory check error
> at 0x00348514 = 0x00, should be 0xFD" which makes little sense to me: why does
> the debugger check memory values while I am deallocating memory? What is it
> looking for, exactly?
>
> Also, this problem occurs only with debug builds: release builds report no
> errors of sort, and the program terminates gracefully.
>
> If anybody has a clue about what goes on exactly, I'd appreciate that.
>
> I haven't posted source code here because the destructors contains just loops of
> delete's, but it's no big secret, I even thought to make it available online as
> public domain once polished, so feel free to ask if you think it's useful.
>
> Thanks in advance.
>
>





Subjectfixed :) new Reply to this message
Posted byTerry Bogard
Posted on01/28/04 06:33 AM



As everyone suggested, seems I was writing outside of the arrays by one byte, the one for the null-terminator. Now the destructor deletes smoothly, thanks everyone.

What leaves me puzzled is the problem popping out when I deallocate, rather than when I actually write to memory. Shouldn't a memory access & modification in an unallocated area of the heap trigger an access violation, rather than a delete? I thought the memory manager would be more "protective"... but maybe I was being too optimistic :P

Again, thanks a lot




SubjectRe: fixed :) new Reply to this message
Posted byBart T.
Posted on01/28/04 11:10 AM



> What leaves me puzzled is the problem popping out when I deallocate, rather than
> when I actually write to memory. Shouldn't a memory access & modification in an
> unallocated area of the heap trigger an access violation, rather than a delete?

Your reasoning is right, but you have to remember that memory protection cannot usually happen at a byte-sized granularity, so you'll often be able to overwrite a few extra bytes without anyone complaining, and that's not good.

Memory protection will typically take place on page-sized (4KB) or greater intervals. X86 has a lot of crazy MMU features but I think Windows probably just uses paging for the most part.

I think you were compiling in debug mode which means MSVC uses code that initializes uninitialized memory regions with a certain magic number (0xFD?) and at the end, checks to see if you have written out of bounds by seeing if everything is 0xFD where it should be. I could be wrong, but I think I've heard this somewhere and it seems consistent with what's happening to you.

----
Bart


SubjectRe: fixed :) new Reply to this message
Posted byTerry Bogard
Posted on01/28/04 12:53 PM



> Your reasoning is right, but you have to remember that memory protection cannot
> usually happen at a byte-sized granularity, so you'll often be able to overwrite
> a few extra bytes without anyone complaining, and that's not good.
>
> Memory protection will typically take place on page-sized (4KB) or greater
> intervals. X86 has a lot of crazy MMU features but I think Windows probably just
> uses paging for the most part.
>
> I think you were compiling in debug mode which means MSVC uses code that
> initializes uninitialized memory regions with a certain magic number (0xFD?) and
> at the end, checks to see if you have written out of bounds by seeing if
> everything is 0xFD where it should be. I could be wrong, but I think I've heard
> this somewhere and it seems consistent with what's happening to you.

I asked google "debug build 0xFD memory" and google said:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_memory_management_and_the_debug_heap.asp

Things one doesn't know without looking around :P





Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode