Find Large Memory leaks in MXFIO lib source

Developers
wangdeq
2004-10-21
2013-04-25
  • wangdeq

    wangdeq - 2004-10-21

    hellow,here
    I just link  the mxflib.lib to a MFC project(eg. a Dialog project).and write the same code as the "main()" of mxfdump to this project.but if I run this fuction.there will be  many memory leaks.
    as belows:

    ---------------------------------
    Dumping objects ->
    {9555} normal block at 0x0137B7A8, 24 bytes long.
    Data: <  S       +4 S  > D4 A8 53 00 01 00 00 00 06 0E 2B 34 02 53 01 01
    {9554} normal block at 0x0137B750, 16 bytes long.
    Data: <  +4 S          > 06 0E 2B 34 02 53 01 01 0D 01 04 01 00 00 00 00
    {9553} normal block at 0x0137B6F8, 16 bytes long.
    Data: <  +4 S          > 06 0E 2B 34 02 53 01 01 0D 01 04 01 00 00 00 00
    {9552} normal block at 0x0137B690, 33 bytes long.
    Data: < localSet       > 00 6C 6F 63 61 6C 53 65 74 00 CD CD CD CD CD CD
    {9550} normal block at 0x0137B608, 65 bytes long.
    Data: < Superclass for > 00 53 75 70 65 72 63 6C 61 73 73 20 66 6F 72 20
    {9540} normal block at 0x0137B208, 24 bytes long.
    Data: <h 7   7     1 0 > 68 AC 37 01 00 90 37 01 CC CD CD CD 31 12 30 01
    {9539} normal block at 0x0137B1A0, 40 bytes long.
    .........................
    -------------------------------- 

    about 800 items.

    same body find it,or how to fix it.

    Regards

    Wandeq

     
    • wangdeq

      wangdeq - 2004-10-21

      I forget it.
      the version is "mxflib-beta-0.5.0-prerel-4"

       
    • wangdeq

      wangdeq - 2004-10-21

      And I find that many "MDOType" object is not destructed while the programe is exited.eg: if we call MDOType::LoadDict(..).there will be about 249 "MDOType" object constructed.but only about 17 object was destructed.

      thanks.

       
      • Matt Beard

        Matt Beard - 2004-10-21

        This is caused by the "Parent" smart pointer in child objects holding the parent object alive after all other references have been released.

        This has now been fixed by introducing a "parent pointer" type which will be available in the next release due out by the end of October.

         
        • Matt Beard

          Matt Beard - 2004-11-08

          The current version on CVS branch Develop-EssenceRead has been checked for memory leaks with Purify and GlowCode. No leaks found.

          This version will be the basis of the full 0.5-Beta release

           

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks