Porting from VC6 to Linux Fedora core 5

Printable View

08-03-2006
g4j31a5

Porting from VC6 to Linux Fedora core 5

Hi, I have encountered a problem. Recently, I ported my codes from Visual C 6 to Linux. But, what I meant about porting was only copy-pasted the entire code to a new KDevelop C/C++ project (also a little letter-case correction in the #include line ). The code was successfully compiled and built. But when I run it, there's a memory corruption error. I don' tknow what's wrong with it because it never happened before in VC6. The error was in the "myVector.push_back(MyObject) ". And the myVector declaration was "vector<*MyObject> myVector". The strange thing was not all of the push_back methods was faulty. Only a few of them. And it gets more strange because when I moved the faulty method to the beginning of the function, it didn't error.

Can someone give an explenation why this occured? and maybe a solution for this problem
thx anyway
08-03-2006
FillYourBrain

push_back calls the copy constructor for that object if I remember correctly. There could be memory access in that call that is a problem. Now, I'm not entirely sure what the result of the dereference operator in vector<*MyObject> is. What is intended?
08-03-2006
g4j31a5

Sorry, my bad. It actually goes like this:

Code:

MyObject* mObject; vector<MyObject*> myVector; //a few object creation lines.... myVector.push_back(mObject);

And the error message was:

*** glibc detected *** ./mattinggame: malloc(): memory corruption:
0x09f67f70 ***

*
======= Backtrace: =========
/lib/libc.so.6[0xb49660]
/lib/libc.so.6(malloc+0x74)[0xb4ac7c]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0x220e4d7]
/usr/lib/libstdc++.so.6(_Znaj+0x1d)[0x220e60d]
./mattinggame[0x8056536]
./mattinggame[0x80567bb]
./mattinggame[0x80578c5]
./mattinggame[0x8057cb2]
./mattinggame[0x8057dd8]
./mattinggame[0x8052b49]
./mattinggame[0x807364c]
./mattinggame[0x807a5ff]
./mattinggame(__gxx_personality_v0+0x1de)[0x80499c2]
/lib/libc.so.6(__libc_start_main+0xdc)[0xafa7e4]
./mattinggame(__gxx_personality_v0+0x9d)[0x8049881]
======= Memory map: ========
001bb000-001be000 r-xp 00000000 fd:00 92170 /usr/lib/libXrandr.so.2.0.0
001be000-001bf000 rwxp 00002000 fd:00 92170 /usr/lib/libXrandr.so.2.0.0
001dd000-001e8000 r-xp 00000000 fd:00 3457623
/lib/libgcc_s-4.1.0-20060304.so.1
001e8000-001e9000 rwxp 0000a000 fd:00 3457623
/lib/libgcc_s-4.1.0-20060304.so.1
00215000-00216000 r-xp 00215000 00:00 0 [vdso]
00258000-00271000 r-xp 00000000 fd:00 3457612 /lib/ld-2.4.so
00271000-00272000 r-xp 00018000 fd:00 3457612 /lib/ld-2.4.so
00272000-00273000 rwxp 00019000 fd:00 3457612 /lib/ld-2.4.so
00548000-00592000 r-xp 00000000 fd:00 75310
/usr/local/lib/libSDL_mixer-1.2.so.0.2.5
00592000-0059c000 rwxp 0004a000 fd:00 75310
/usr/local/lib/libSDL_mixer-1.2.so.0.2.5
0059c000-005c0000 rwxp 0059c000 00:00 0
00680000-006e3000 r-xp 00000000 fd:00 71301
/usr/local/lib/libSDL-1.2.so.0.11.0
006e3000-006e5000 rwxp 00063000 fd:00 71301
/usr/local/lib/libSDL-1.2.so.0.11.0
006e5000-00700000 rwxp 006e5000 00:00 0
00ae5000-00c11000 r-xp 00000000 fd:00 3457618 /lib/libc-2.4.so
00c11000-00c14000 r-xp 0012b000 fd:00 3457618 /lib/libc-2.4.so
00c14000-00c15000 rwxp 0012e000 fd:00 3457618 /lib/libc-2.4.so
00c15000-00c18000 rwxp 00c15000 00:00 0
00c1a000-00c3d000 r-xp 00000000 fd:00 3457619 /lib/libm-2.4.so
00c3d000-00c3e000 r-xp 00022000 fd:00 3457619 /lib/libm-2.4.so
00c3e000-00c3f000 rwxp 00023000 fd:00 3457619 /lib/libm-2.4.so
00c41000-00c43000 r-xp 00000000 fd:00 3457620 /lib/libdl-2.4.so
00c43000-00c44000 r-xp 00001000 fd:00 3457620 /lib/libdl-2.4.so
00c44000-00c45000 rwxp 00002000 fd:00 3457620 /lib/libdl-2.4.so
00c47000-00d40000 r-xp 00000000 fd:00 92167 /usr/lib/libX11.so.6.2.0
00d40000-00d44000 rwxp 000f9000 fd:00 92167 /usr/lib/libX11.so.6.2.0
00d46000-00d48000 r-xp 00000000 fd:00 92165 /usr/lib/libXau.so.6.0.0
00d48000-00d49000 rwxp 00001000 fd:00 92165 /usr/lib/libXau.so.6.0.0
00d60000-00d65000 r-xp 00000000 fd:00 92166 /usr/lib/libXdmcp.so.6.0.0
00d65000-00d66000 rwxp 00004000 fd:00 92166 /usr/lib/libXdmcp.so.6.0.0
00d68000-00d77000 r-xp 00000000 fd:00 92169 /usr/lib/libXext.so.6.4.0
00d77000-00d78000 rwxp 0000e000 fd:00 92169 /usr/lib/libXext.so.6.4.0
00dc7000-00dcf000 r-xp 00000000 fd:00 92168 /usr/lib/libXrender.so.1.3.0
00dcf000-00dd0000 rwxp 00007000 fd:00 92168 /usr/lib/libXrender.so.1.3.0
00dd2000-00de2000 r-xp 00000000 fd:00 3457622 /lib/libpthread-2.4.so
00de2000-00de3000 r-xp 0000f000 fd:00 3457622 /lib/libpthread-2.4.so
00de3000-00de4000 rwxp 00010000 fd:00 3457622 /lib/libpthread-2.4.so
00de4000-00de6000 rwxp 00de4000 00:00 0
00de8000-00df1000 r-xp 00000000 fd:00 92172 /usr/lib/libXcursor.so.1.0.2
00df1000-00df2000 rwxp 00008000 fd:00 92172 /usr/lib/libXcursor.so.1.0.2
00df4000-00df8000 r-xp 00000000 fd:00 92171 /usr/lib/libXfixes.so.3.0.0
00df8000-00df9000 rwxp 00003000 fd:00 92171 /usr/lib/libXfixes.so.3.0.0
02157000-02239000 r-xp 00000000 fd:00 92179 /usr/lib/libstdc++.so.6.0.8
02239000-0223d000 r-xp 000e2000 fd:00 92179 /usr/lib/libstdc++.so.6.0.8
0223d000-0223e000 rwxp 000e6000 fd:00 92179 /usr/lib/libstdc++.so.6.0.8
0223e000-02244000 rwxp 0223e000 00:00 0
08048000-08087000 r-xp 00000000 fd:00 1533373
/home/benang/mattinggame/debug/src/mattinggame
08087000-08088000 rw-p 0003e000 fd:00 1533373
/home/benang/mattinggame/debug/src/mattinggame
098e0000-09d85000 rw-p 098e0000 00:00 0 [heap]
b4a00000-b4a21000 rw-p b4a00000 00:00 0
b4a21000-b4b00000 ---p b4a21000 00:00 0
b4b2d000-b6a5d000 rw-p b4b2d000 00:00 0
b6a5d000-b6b89000 rw-s 00000000 00:08 3112963 /SYSV00000000 (deleted)
b6b89000-b6b8a000 ---p b6b89000 00:00 0
b6b8a000-b758a000 rw-p b6b8a000 00:00 0
b758a000-b758b000 ---p b758a000 00:00 0
b758b000-b7f8e000 rw-p b758b000 00:00 0
b7fa6000-b7fa9000 rw-p b7fa6000 00:00 0
bff93000-bffa9000 rw-p bff93000 00:00 0 [stack]
/bin/sh: line 1: 27410 Aborted ./mattinggame

BTW, I've changed the code into MyObject **mObject and the object was created by :"mObject = new MyObject[mCount]". It worked fine until a while. When I uncommented a large part of the code, it gone berserk again.
08-03-2006
Ancient Dragon

why don't you post some real code so that we can see how the objects are created and used. The problem is obviously somewhere other than in the fake code you posted.
08-03-2006
Mario F.

If you are using the default copy constructor, the problem is almost certainly there. Otherwise, try to create an empty one and see if it goes away:

MyObject& operator=(const MyObject& robj);
08-03-2006
FillYourBrain

except that its a vector of pointers. The 'copy constructor' for a pointer is just an assignment. I think he's ok there. It's probably some misuse of dynamic memory.

post code
08-03-2006
Salem

You could try either

g++ -g prog.cpp -lefence
gdb ./a.out

Or
valgrind ./a.out

Both of which should get you closer to where memory is first corrupted, rather than in some unrelated area which first notices there is a problem.
08-04-2006
g4j31a5

Well, I can't give you the full code cause it has already evolving into a "small" giant. Here's a part of it though:

in main

Code:

int main(argc,argv) { CImageHandler* mImgHandler; //Object for handling pointer to bitmap images mImgHandler = new mImgHandler("ImgHandler.cfg"); //Constructor with a filename consisting the names of Bitmap Images //Objects that will be displayed in the surface CObjectScene* mObject1; CObjectScene* mObject2; CObjectScene* mObject3; CObjectScene* mObject4; .... //There's a lot of objects mObject1 = new CObjectScene(mImgHandler, "Obj1.cfg"); mObject2 = new CObjectScene(mImgHandler, "Obj2.cfg"); mObject3 = new CObjectScene(mImgHandler, "Obj3.cfg"); mObject4 = new CObjectScene(mImgHandler, "Obj4.cfg"); //ERROR here!!! ..... //Other objects /* Some rendering loop functions */ return 0; }

in CImageHandler

Code:

typedef map<string, CBmpImage *> lstImage; typedef lstImage::iterator itrImage; class CImageHandler { public: //Constructor CImageHandler(char* filename) { char imgname[255], filename[255]; CBmpImage* tempImg; char buffer[255]; FILE *fp=fopen(filename,"r"); /* Function to extract the configuration of each images from the file. Consist of image's name & image filename*/ while(!feof(fp)) { fgets(buffer,255,fp); sscanf(buffer,"%s %s",imgname, filename); tempImg = new CBmpImage(imgname, filename); //Create & insert image to map mImages[imgname]=tempImg; } fclose(fp); } CBmpImage* getImage(string name) { return mImages.find(name)->second; } private: lstImage mImages; }

in the CObjectScene

Code:

struct AnimFrame { CBmpImage *theImg; int delay; }; typedef vector<AnimFrame *> lstFrames; //List of an animation's frames typedef lstImage::iterator itrFrames; class CObjectScene { public: CObjectScene(CImageHandler *imghandler, char* filename) { char imgname[255]; int tempdelay; char buffer[255]; FILE *fp=fopen(filename,"r"); /* Function to extract the configuration of each objects from the file. Consist of image's name & delay to the next frame*/ while(!feof(fp)) { fgets(buffer,255,fp); sscanf(buffer,"%s %d",imgname, tempdelay); AnimFrame *temp = new AnimFrame; temp->theImg=imghandler->getImage(imgname); temp->delay=tempdelay; mFrames.push_back(temp); //ERROR here for the 4th object. The other previous objects are fine. } fclose(fp); } private: lstFrames mFrames; }

Can you help me please?
08-04-2006
g4j31a5

I have suspected the cause but I didn't quite sure. In making the CBmpImage objects in CImageHandler, I used this code:

Code:

..... CBmpImage { public: CBmpImage(char* imgname,char* filename) { mName= new char[strlen(imgname)]; strcpy(mName,imgname); loadBmp(filename); } private: char* mName; } .....

I suspected the :

Code:

mName= new char[strlen(imgname)]; strcpy(mName,imgname);

code because I can't delete the mName in the class's destructor. Anybody can give me some enlightment here? Please???
08-04-2006
Ancient Dragon

that is not allocating enough memory -- need one more byte for the null terminator

Code:

mName= new char[strlen(imgname)+1]; strcpy(mName,imgname);
08-04-2006
g4j31a5

Quote:

Originally Posted by Ancient Dragon

that is not allocating enough memory -- need one more byte for the null terminator

Code:

mName= new char[strlen(imgname)+1]; strcpy(mName,imgname);

Thanks, but you know what, after I changed all occurences of "char*" into "std::string", the problem goes away. What a relief!!! Thank you all..
08-04-2006
Salem

> while(!feof(fp))
1. Read the FAQ
2. Why are you using C-style file I/O in a C++ program?

> strcpy(mName,imgname);
Had you run the code linked against the electic fence and run the code in the debugger, you would likely have gotten a trap, and the stack trace would lead back to the strcpy...
Maybe try it with your old code and see if you can find the bug using the tools, now that you know where the bug is?

Then you'll be in a much better position to find your next memory mystery problem.
08-06-2006
g4j31a5

Quote:

Originally Posted by Salem

> while(!feof(fp))
1. Read the FAQ
2. Why are you using C-style file I/O in a C++ program?

Because it's the only way I know to access files. My basic is afterall C not C++. That's why I have a trouble using STL and such.

Quote:

> strcpy(mName,imgname);
Had you run the code linked against the electic fence and run the code in the debugger, you would likely have gotten a trap, and the stack trace would lead back to the strcpy...
Maybe try it with your old code and see if you can find the bug using the tools, now that you know where the bug is?

Then you'll be in a much better position to find your next memory mystery problem.

Err... I don't think I understand what you're saying. When I debugged it, it didn't show any error (at least in VC6). I didn't take note of the memory allocation in debug back then. That's why when I changed to Linux, I don't know what went wrong.
08-06-2006
Salem

> When I debugged it, it didn't show any error (at least in VC6).
That just means you were lucky, not good.

Different implementations do different things with memory allocations, so a small overstep on one platform might go undetected for a very long time, but would become immediately apparent on another. Which seems to describe your experience.

Debugging is more than "it produces the output I want and it doesn't crash".

> That's why when I changed to Linux, I don't know what went wrong.
Nothing went wrong, it's just the change of scenery caused a previously hidden bug to show up. It happens a lot when you compile code on a new platform for the first time.
08-07-2006
g4j31a5

Quote:

Originally Posted by Salem

> When I debugged it, it didn't show any error (at least in VC6).
That just means you were lucky, not good.

Yeah, I learnt that the hard way. :P

Quote:

Different implementations do different things with memory allocations, so a small overstep on one platform might go undetected for a very long time, but would become immediately apparent on another. Which seems to describe your experience.

Debugging is more than "it produces the output I want and it doesn't crash".

So, what is the good and effective debugging? It has been a weak point of mine since a long time ago. Especially if it concerns memory.
08-07-2006
Perspective

>So, what is the good and effective debugging?

Compile with the -g flag and run gdb (or a GUI interface to gdb like DDD or Eclipse's CDT) on the executable.
08-07-2006
Salem

> So, what is the good and effective debugging?
For memory debugging, using the tools I suggested. Test as you go, so that you spot early on any overwrites or memory leaks.

Also consider tools like lint which perform static analysis on the code to spot bugs.

For memory allocations, try and create wrapper functions to allocate, extend and free, and very carefully debug them in isolation before integrating them into the main project.
Also, keep such code very simple - it's all too easy to outsmart yourself when dynamically allocating and freeing stuff.

For example, I often allocate memory then go and figure out all the places where the free should happen, and make sure it does before complicating matters further.
08-08-2006
g4j31a5

I used KDevelop with GDB debugger. What I did in debugging was only looking at the values of each variables. I didn't even use assert and try-catch-throw whatsoever. I don't have any experience with them. Maybe that's one of my faults.

So, when the debugger showed the memory allocation or any assembly lines, I don't know how to read them. That's one more of my weaknesses. Can you help me understand them?