Thread: Porting from VC6 to Linux Fedora core 5

  1. #1
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476

    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

  2. #2
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    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?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  3. #3
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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.
    Last edited by g4j31a5; 08-03-2006 at 05:18 AM.

  4. #4
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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.

  5. #5
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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);
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #6
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    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
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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?
    Last edited by g4j31a5; 08-04-2006 at 03:38 AM.

  9. #9
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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???

  10. #10
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    that is not allocating enough memory -- need one more byte for the null terminator
    Code:
    mName= new char[strlen(imgname)+1];
      strcpy(mName,imgname);

  11. #11
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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..

  12. #12
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  13. #13
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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.

    > 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.

  14. #14
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  15. #15
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    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

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Porting to Linux?
    By cpjust in forum C Programming
    Replies: 3
    Last Post: 10-18-2007, 05:46 PM
  2. wxWidgets, porting from Linux to PDA
    By BobS0327 in forum Tech Board
    Replies: 0
    Last Post: 05-16-2006, 08:25 AM
  3. Replies: 1
    Last Post: 10-18-2005, 10:20 AM
  4. gcc problems with Fedora Core 3
    By phldml3 in forum C Programming
    Replies: 4
    Last Post: 06-11-2005, 12:34 AM
  5. Porting the NES emulator from DOS to Linux
    By billholm in forum Game Programming
    Replies: 14
    Last Post: 08-03-2002, 01:48 AM