Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Integrating libjson into MFC application

Help
Gerry Iles
2012-07-11
2013-06-12
  • Gerry Iles
    Gerry Iles
    2012-07-11

    Hi,

    I am trying to integrate the C++ libjson code (version 7.6.1) into an existing MFC based Windows application built using VS2008.  I have managed to include all the files and configured JSONOptions.h such that I can use JSONWorker::parse and also build trees of JSONNode and call JSONNode::write to output them but when I do call JSONWorker::parse then the application reports memory leaks on exit.  Even with a trivial parse, e.g.

      json_string sInput(_T("{}"));
      JSONNode jsInput = JSONWorker::parse(sInput);

    …when the application exits it reports several memory leaks:

    {19530} normal block at 0x086B8CA0, 48 bytes long.
    Data: <        JSONNode> 00 00 00 00 CD CD CD CD 4A 53 4F 4E 4E 6F 64 65
    {19529} normal block at 0x05F69088, 48 bytes long.
    Data: <        jsonChil> 00 00 00 00 CD CD CD CD 6A 73 6F 6E 43 68 69 6C
    {19528} normal block at 0x05F69028, 32 bytes long.
    Data: <internalJSONNode> 69 6E 74 65 72 6E 61 6C 4A 53 4F 4E 4E 6F 64 65
    {19527} normal block at 0x05F68FB8, 48 bytes long.
    Data: <        (       > 00 00 00 00 CD CD CD CD 28 90 F6 05 CD CD CD CD
    {19523} normal block at 0x05F68EE8, 48 bytes long.
    Data: <        json_aut> 00 00 00 00 CD CD CD CD 6A 73 6F 6E 5F 61 75 74
    {19521} normal block at 0x05F68E20, 48 bytes long.
    Data: <        JSONNode> 00 00 00 00 CD CD CD CD 4A 53 4F 4E 4E 6F 64 65
    {19519} normal block at 0x05F68DB0, 48 bytes long.
    Data: <        jsonChil> 00 00 00 00 CD CD CD CD 6A 73 6F 6E 43 68 69 6C
    {19516} normal block at 0x086B8E18, 32 bytes long.
    Data: <internalJSONNode> 69 6E 74 65 72 6E 61 6C 4A 53 4F 4E 4E 6F 64 65
    {19515} normal block at 0x086B8DA8, 48 bytes long.
    Data: <          k     > 00 00 00 00 CD CD CD CD 18 8E 6B 08 CD CD CD CD
    {19507} normal block at 0x086BECB0, 48 bytes long.
    Data: <        json_aut> 00 00 00 00 CD CD CD CD 6A 73 6F 6E 5F 61 75 74

    These memory leaks don't appear to depend on what is parsed, just that something is.  Is there some global/static memory allocation going on inside the libjson code that isn't being cleaned up?  Is there a way to clean it up?  I've not found any mention in the docs but I also don't see any mention of JSONWorker in there…

    Thanks,
      Gerry

     
  • This is statics and globals.  libjson has unit tests and has been valgrinded.  It does not leak memory.

     
  • Gerry Iles
    Gerry Iles
    2012-07-17

    I have since found that these allocations are being done by the singleton mechanism you use for "global" declarations (in JOSNGlobals.h) and possibly also by the error callback mechanism.  While your comment about this making the library faster to initialise and have a smaller memory footprint is true, in my use case neither of these points are as important as having accurate memory leak reporting or ensuring that it doesn't break (or really leak memory) if two threads happen to both do the first access to the same global at the same time.

    Would you consider adding another define in JSONOptions.h that disables the use of this singleton mechanism?  Alternatively, it could still use the singletons but could be given a pair of init and deinit functions that explicitly allocate and deallocate all of these globals.

    Thanks,
      Gerry

     
  • Detlef
    Detlef
    2012-08-08

    Hi,

    I am experiencing similar memory leak messages like Gerry. I'm using Visual Studio 2010.

    Although the count of leaks seem to be stable regardless how often I call jsonlib::parse(), it is very annoying and makes debugging error-prone. I have tried to use the json_free_all() but this function isn't exposed if you use the C++ interface. If the problem lies in the "skeleton mechanism" like described by Gerry, maybe going back a few jsonlib releases (before skeleton was built in) would help.

    Best regards,
    Detlef

     
  • Oh, I didn't realize windows developers would have issues with this.  I guess valgrind has spoiled me, I will try and add a way to remove the allocate when needed behavior.

    json_free_all will not free the memory used by the singletons, it only frees strings and nodes that are returned to the user.

     
  • Detlef
    Detlef
    2012-08-08

    I would highly appreciate that!

    One more thing: I fiddled with the make options and encountered a compile error in JSONMemory.cpp, line42. Somehow a character "`" (ascii value 0x60) slipped into the code line. Maybe it's already fixed, I'm working with version 7.6.1.

     
  • What the bloody hell?  I have a test suite of a million tests, how did that sneak through?

    I added a way to setup and teardown all of the singletons at once.  It will be available shortly.