Programming Forums - Memory problems

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C++ (http://www.programmingforums.org/forum15.html)

- - Memory problems (http://www.programmingforums.org/showthread.php?t=12719)

Hi everybody,
i'm currently working on a little project of mine. But I get a strange error, and it have probably something to do with the memory. I'm don't know much about debugging, so I've hard to do something against it. The error that occurs is:

Quote:

Application error
The instruction at "0x7c911e58" referring to memory at "0x000043eb". The memory couldn't "read".

Click OK to terminate the application

I've then tried to use GDB, both by hand and the integrated one in Dev-C++. In Dev-C++' debug-area it looks like this:

Quote:

...

signal
Program received signal
signal-name
SIGTRAP
signal-name-end
,
signal-string
Trace/breakpoint trap
signal-string-end
.
frame-begin 0 0x7c901231
frame-address
0x7c901231
frame-address-end
in
frame-function-name
_libuser32_a_iname
frame-args
()
frame-end
stopped
pre-prompt
(gdb)
prompt
warning: Heap corruption detected at 000348A0
warning: HEAP[AppName.exe]:
warning: Heap block at 00034858 modified at 00034

The problem is that I've no line numbers, so I don't know where to look and fix. I hope someone can help me fix this!

EDIT:
I just tried a backtrace, and now I got some more information, and linenumbers.

#0  0x7c901231 in _libuser32_a_iname ()

#1  0x7c96c943 in _libuser32_a_iname ()

#2  0x7c95db9c in _libuser32_a_iname ()

#3  0x7c96cd11 in _libuser32_a_iname ()

#4  0x7c96df66 in _libuser32_a_iname ()

#5  0x7c94a5d0 in _libuser32_a_iname ()

#6  0x7c9268ad in _libuser32_a_iname ()

#7  0x77c1c2de in _libuser32_a_iname ()

#8  0x00416785 in operator delete(void*) ()

#9  0x00405b3d in GUI::ListView::~ListView() (this=0x45e4c0)

    at listview.cpp:155

#10 0x00403246 in __static_initialization_and_destruction_0(int, int) (

    __initialize_p=0, __priority=65535) at listview.hpp:41

#11 0x004032b4 in _GLOBAL__D__ZN9Functions8char2intEPc () at main.cpp:254

#12 0x0041fab2 in __do_global_dtors ()

#13 0x77c29e24 in _libuser32_a_iname ()

#14 0x77c29ec5 in _libuser32_a_iname ()

listview.cpp ~ Line 155

delete [] this->Thread_IDs;

listview.hpp ~ Line 41

} static ListViewHandle;

main.cpp ~ Line 254

There is no line 254, maximum line is 253, which is a newline.

The error is being detected when destructors for some global object is being invoked (i.e. after main() returns in your program).

The cause could be almost anything. My guess would be that you've molested an innocent pointer somewhere in your code, although it is possible the cause is a bug in some library function that you've used. That has corrupted something, but the symptoms aren't made visible until later.

As to how you find it, selectively commenting out parts of your code, rebuilding, and seeing if the problem still occurs will help you narrow down the cause. But that takes a fair amount of effort.

I'll try what you said. I just thought there maybe was some other, smart, way to do it. But thanks for your reply!

The smart way is to design your program and use coding practices that prevent the problem in the first place. That usually implies testing small bits, proving they work, combining those small bits into bigger bits and proving they work, until you have confidence that the whole program works correctly.

Given that you're starting with the end result (a crashing program) you need to work backward via "divide and conquer": eliminate things that don't contribute to the problem, and eventually converge on the cause. There is no smart solution, as you have already ignored the smart steps. A debugger MIGHT help, but to use a debugger to find a problem, you need to have some idea of what you're looking for (eg what function is causing the problem) unless you want to step through every function you have one line at a time. And, given the nature of the problem (some area of memory being corrupted that causes a later crash) it will be hard to find with a debugger unless, again, you have narrowed down the potential causes.

The application did work just fine, but when I tried to implement something I'd forgot earlier, the application crashed. It's probably in the new code the error is, but I don't have the time to look at it right now, so I can't reply if it's that, now.

Looking at your new code is a good place to start. Keep in mind that it is not 100% certain that the problem is in your new code.

One common issue associated with pointer abuse is that removal of some unrelated code can make the symptoms disappear i.e. it is possible the problem was in your original application, but your new code changed memory layout of your application in a way that just made symptoms become visible.

Damn. I can't find the error at all.
I tried to set a messagebox into the destructor to see what happening, and to my big suprise, the ListViewHandle's destructor is being called twice. I thought it normally is just one time. Is that normal behavior? Is it because ListViewHandle is static?

EDIT:
I just debugged again, and I can see that it's in the second call to the destructor it fails.

EDIT, EDIT:
I fixed the problem with two calls to the destructor, it was because I'd initialized the objects in the header-files. Now I'd make them extern in header-files, and finally initialized them in my main-file. I'm still getting the same error, when entering the destructor. But I'm not so sure that it's actually in the destructor, because when debugging, it's like it's before, so I'll take alook at it all again.

What you're describing is chasing the symptom and not the cause. I would bet good money that the cause of the problem is not in the destructor and not in code deleting the objects. I would further bet that the cause is in code that is invoked somewhere before you get to that point.

I'm now working backward, which is a pretty stupid thing.
I've still not found the bug, but it wasn't in the destructor. Now I'm getting errors with one of my other classes, Web.
There's an error, without description at this line;

delete [] this->Page;

I think it's probably some bad-allocated memory that's bugging me.
I also get a error on line 261, in my mainfile, which doesn't exists. It's 'bout a global function in the namespace Functions.

// functions.hpp

#ifndef FUNCTIONS_HPP

#define FUNCTIONS_HPP



namespace Functions

{

// ...

        int char2int(char *charString)

        {

                int integer;

                std::stringstream SS;

                SS << charString;

                SS >> integer;

                return integer;

        }

// ...

}



#endif



// ------------------------------------------

// The use of this class in main.cpp

#include "functions.hpp"

// ...

int temp_var = Functions::char2int("123"); // Example

Isn't this the correct way to do it?

I think I just have to start from the scratch with this project, it seems like everything goes wrong for me at the time.

(I LIKE TO) EDIT:
I got my application working again!
It was, as far as I can see, bad allocated memory, but I'm still worry, because I think there's still some bugs "out there", but I'm not sure. I'll finish this version of the application, and then the next version vil be totally re-coded. It's just a project for myself, so nobody will be angry, if some error occurs.

:confused: I have provided you a number of pointers to potential causes, but you insist on ignoring them.

In my experience, about 95% of problems with operator delete, or that occur after main() has returned, are a result of a previous pointer molestation. Most of the rest are related to misuse of operator delete (eg mix of operator new without [] and operator [], or deallocating a pointer alloocated by malloc() using operator delete).

If you have a problem of "bad-allocated" memory, then an exception would have been thrown when you used operator new. You would have had to go out of your way to ignore such an error.

Look for instances of dereferencing a NULL pointer, falling off the end of an array, dereferecing an uninitialised pointer, etc. But look in code BEFORE the point where the crash occurs.

Note to self: if v0id offers me software, run a mile