5 Replies Latest reply: Aug 23, 2012 3:48 PM by 956974 RSS

    OCCI and valgrind

    956974
      Hello,

      I wrote a simple OCCI program and ran valgrind with it. I got some memory leak in the program. I tried to search around but couldn't get any answers. I have tried to compile the program using gcc version 4.5, and icpc version 12.0.4 and they both gave the same errors. The OS I am using is RedHat Linux 6.1.

      Could someone help me please ? Here's the program:


      #include "occi.h"
      #include <iostream>
      #include <string>

      int main()
      {
      oracle::occi::Environment *theOCCIEnvPtr = NULL;

      try
      {
      theOCCIEnvPtr = oracle::occi::Environment::createEnvironment(oracle::occi::Environment::DEFAULT);

      oracle::occi::Environment::terminateEnvironment(theOCCIEnvPtr);
      } catch (...){
      std::cout << "Caught an exception" << std::endl;
      }

      return 0;
      }

      and one of the leaks is :

      ==9744== 32 bytes in 1 blocks are definitely lost in loss record 61 of 224
      ==9744== at 0x4A07279: malloc (vg_replace_malloc.c:263)
      ==9744== by 0x62D9147: slzsetevar (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x62DCD8F: lfvSetOHome (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x568DB23: slpmloclfv (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x568D72E: slpmloc (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x568B1AF: lpmloadpkg (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x566F800: lfvLoadPkg (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x566F4B5: lfvSetShlMode (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x566F2E7: lfvini1 (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x566F13E: lfvini2 (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x55E47AC: lxlinit (in /apps/oracle_client/libclntsh.so.11.1)
      ==9744== by 0x5527204: nleminz (in /apps/oracle_client/libclntsh.so.11.1)
        • 1. Re: OCCI and valgrind
          957177
          Same problem here.

          I wrote this simple application:

          #include <occi.h>
          #include <iostream>
          #include <iomanip>

          using namespace oracle::occi;
          using namespace std;

          int main(int argc, char** argv) {
          Environment *env;
          Connection *con;

          string user;
          string passwd;
          string db;

          env = Environment::createEnvironment(Environment::DEFAULT);

          try
          {
          con = env->createConnection("test", "test", "10.20.30.101:1521");
          }
          catch (SQLException& ex)
          {
          cout << ex.getMessage();
          }

          env->terminateConnection (con);

          Environment::terminateEnvironment (env);
          }

          and valgrind found some memory leak here:


          ==7833== 46 bytes in 1 blocks are definitely lost in loss record 65 of 219
          ==7833== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
          ==7833== by 0x6B6F397: slzsetevar (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x6B7306F: lfvSetOHome (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C54E2F: slpmloclfv (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C54A3A: slpmloc (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C52512: lpmloadpkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C369DC: lfvLoadPkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C36691: lfvSetShlMode (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C364C3: lfvini1 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C3631A: lfvini2 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5BAF930: lxlinit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5B4ED90: nleminz (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833==
          ==7833== 192 bytes in 1 blocks are possibly lost in loss record 148 of 219
          ==7833== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
          ==7833== by 0x5C3311C: sltsmxi (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4EB8B: lmmhpinit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4DDDD: lmmcis (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C52C40: lpmpali (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51F04: lpminitm (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51CEB: lpminit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C36997: lfvLoadPkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C36691: lfvSetShlMode (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C364C3: lfvini1 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C3631A: lfvini2 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5BAF930: lxlinit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833==
          ==7833== 192 bytes in 1 blocks are possibly lost in loss record 149 of 219
          ==7833== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
          ==7833== by 0x5C3311C: sltsmxi (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4EB8B: lmmhpinit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4DDDD: lmmcis (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C52C40: lpmpali (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C524CA: lpmloadpkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C369DC: lfvLoadPkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C36691: lfvSetShlMode (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C364C3: lfvini1 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C3631A: lfvini2 (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5BAF930: lxlinit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5B4ED90: nleminz (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833==
          ==7833== 139,264 bytes in 1 blocks are possibly lost in loss record 219 of 219
          ==7833== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
          ==7833== by 0x5C515F8: slwmmgetmem (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51390: lmmstvrt (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4FD1D: lmmstchnk (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51215: lmmstsml (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x74A0809: lmmstmalloc (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x749FE3D: lmmmalloc (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C4DCCC: lmmcis (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C52C40: lpmpali (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51F04: lpminitm (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C51CEB: lpminit (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833== by 0x5C36997: lfvLoadPkg (in /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1)
          ==7833==

          I've compiled the program with eclipse with the libraries provided with the istant client 11.2.3.0 for linux x64 on debian wheezy with 3.2.0-3-amd64 kernel.

          someone can help?
          • 2. Re: OCCI and valgrind
            jim dc
            Interesting, but it seems a bit academic - is there a case where you would terminate the environment without closing your process anyway, in which case the memory leak is irrelevant. I'd be more impressed by the leak if it was coming in a loop of CreateStatement, TerminateStatement or something like that.
            • 3. Re: OCCI and valgrind
              956974
              I tried a different combinations of things and looked at the valgrind summary.

              (1) The amount of leak stays about the same, so I guess it's not a huge issue, however it does hide away some memory problems not from OCCI.
              (2) There are a bunch of memory errors in some cases. (conditional jump or move depends on uninitialised value(s), use of uninitialised value of size 8).

              I could try to use suppression file to filter out some problems, but there seem to be alot.



              Here are the things I have tried :

              I : (Only has createEnvironment, and terminateEnvironment)

              ==18538== LEAK SUMMARY:
              ==18538== definitely lost: 32 bytes in 1 blocks
              ==18538== indirectly lost: 0 bytes in 0 blocks
              ==18538== possibly lost: 139,648 bytes in 3 blocks
              ==18538== still reachable: 388,972 bytes in 223 blocks
              ==18538== suppressed: 0 bytes in 0 blocks

              =======================================================================================

              II : I + open/close connection


              ==18517== LEAK SUMMARY:
              ==18517== definitely lost: 32 bytes in 1 blocks
              ==18517== indirectly lost: 0 bytes in 0 blocks
              ==18517== possibly lost: 139,648 bytes in 3 blocks
              ==18517== still reachable: 760,698 bytes in 261 blocks
              ==18517== suppressed: 0 bytes in 0 blocks

              ERROR SUMMARY: 2715 errors from 345 contexts (suppressed: 4 from 4)

              =======================================================================================

              III : II + creating one statment, query for result, closeReturnSet, terminateStatement

              ==18584== LEAK SUMMARY:
              ==18584== definitely lost: 32 bytes in 1 blocks
              ==18584== indirectly lost: 0 bytes in 0 blocks
              ==18584== possibly lost: 139,648 bytes in 3 blocks
              ==18584== still reachable: 760,698 bytes in 261 blocks
              ==18584== suppressed: 0 bytes in 0 blocks

              ==18584== ERROR SUMMARY: 2731 errors from 346 contexts (suppressed: 4 from 4)

              =======================================================================================

              IV : III + query for result one more time using setSQL (using the same statement)

              ==18636== LEAK SUMMARY:
              ==18636== definitely lost: 32 bytes in 1 blocks
              ==18636== indirectly lost: 0 bytes in 0 blocks
              ==18636== possibly lost: 139,648 bytes in 3 blocks
              ==18636== still reachable: 760,698 bytes in 261 blocks
              ==18636== suppressed: 0 bytes in 0 blocks

              ==18636== ERROR SUMMARY: 2734 errors from 346 contexts (suppressed: 4 from 4)

              =======================================================================================

              V : III + creating one more statment and use the 2nd statement for query.

              ==18731== LEAK SUMMARY:
              ==18731== definitely lost: 32 bytes in 1 blocks
              ==18731== indirectly lost: 0 bytes in 0 blocks
              ==18731== possibly lost: 139,648 bytes in 3 blocks
              ==18731== still reachable: 760,698 bytes in 261 blocks
              ==18731== suppressed: 0 bytes in 0 blocks
              ==18731==
              ==18731== ERROR SUMMARY: 2735 errors from 347 contexts (suppressed: 4 from 4)
              • 4. Re: OCCI and valgrind
                jim dc
                I would encourage you to submit the problem to Oracle Support - as you say its annoying if it masks other problems

                Does the environment->getCurrentHeapSize() call show a leak?

                One other thought - any leaks in OCI, which underlies OCCI, will also manifest themselves in OCCI. There are quite a few hits on the 'Call Interface' forum for memory leak, but I didnt bother looking too closely.

                You didnt mention what version of Oracle client you are on. The other poster said 11.2.0.3
                Good luck
                • 5. Re: OCCI and valgrind
                  956974
                  Thanks for your suggestion, I'm waiting for approval to use the support identifier, hopefully I can submit a question to Oracle support soon.

                  The version I am using is 11.2.0.1.0.


                  I tried to print out getcurrentHeapSize after every OCCI calls. It seems like there are memory leak between pairs of createStatement/terminateStatement, executeQuery/closeResultSet, however, terminateConnection frees everything and back to the original heap size (just after createEnvironment). So I guess the leak reported by Valgrind comes from createEnvironment/closeEnvironment.


                  Thank you again for your help!