sfcb binary interface memory leak on CMGetObjectPath

Logged In: YES
user_id=1550470
Originator: NO

could you attach the section of the valgrind output that reports this and perhaps the code that causes it? Does the error occur for /every/ connection when SfcbLocal is used? Also, what version of sfcb and sfcc are you using?

Logged In: YES
user_id=2045322
Originator: YES

Here is the code snippet from sfcc:

CMCIClient *cc = NULL;
CMPIObjectPath * objectpath = NULL;
CMPIObjectPath * temp_objectpath = NULL;
CMPIEnumeration * enumeration = NULL;
CMPIData data;
CMPIStatus status;
char *namespace = "root/cimv2";

//ClassName to be enumerated
char \*classname = "CIM\_AdminDomain";

cc = cmciConnect\("localhost", "SfcbLocal",
                                    NULL,NULL, NULL, &status\);

if\(status.rc\)
\{
    fprintf\(stderr,
                    "Could not connect to CIMOM"
                    ". Check if it is running as"
                   "    well as your parameters.\n"\);
    return -1;
\}

objectpath = newCMPIObjectPath\(namespace, classname, NULL\);
enumeration = cc->ft->enumInstances\(cc, objectpath, 0, NULL, &status\);

while\(CMHasNext\(enumeration, NULL\)\)
\{
    data = CMGetNext\(enumeration, NULL\);
    if\(data.type == CMPI\_instance\)
    \{
            temp\_objectpath = CMGetObjectPath\(data.value.inst,NULL\);
            CMRelease\(temp\_objectpath\);

    \}
\}

CMRelease\(objectpath\);
CMRelease\(enumeration\);

CMRelease\(cc\);

we have tried to establish a connection and after doing a enumerateinstances tried to fetch the objectpath using CMGetObjectPath. valgrind shows the leak exactly at that place. Have attached the valgrind output also. while commenting out the CMGetObjectPath valgrind does not report the leak.

I am using sfcb 1.2.5.
I am not using sfcc. we have our own CIM client.

valgrind report:

==18307== 8 bytes in 2 blocks are definitely lost in loss record 1 of 16
==18307== at 0x4005400: malloc (vg_replace_malloc.c:149)
==18307== by 0x4F1C5EE7: _dl_map_object_from_fd (in /lib/ld-2.5.so)
==18307== by 0x4F1C7403: _dl_map_object (in /lib/ld-2.5.so)
==18307== by 0x4F1CB195: openaux (in /lib/ld-2.5.so)
==18307== by 0x4F1CCC05: _dl_catch_error (in /lib/ld-2.5.so)
==18307== by 0x4F1CB759: _dl_map_object_deps (in /lib/ld-2.5.so)
==18307== by 0x4F1D06C4: dl_open_worker (in /lib/ld-2.5.so)
==18307== by 0x4F1CCC05: _dl_catch_error (in /lib/ld-2.5.so)
==18307== by 0x4F1D0191: _dl_open (in /lib/ld-2.5.so)
==18307== by 0x4FCFAD0C: dlopen_doit (in /lib/libdl-2.5.so)
==18307== by 0x4F1CCC05: _dl_catch_error (in /lib/ld-2.5.so)
==18307== by 0x4FCFB38B: _dlerror_run (in /lib/libdl-2.5.so)
==18307==
==18307==
==18307== 28 (4 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 16
==18307== at 0x4005400: malloc (vg_replace_malloc.c:149)
==18307== by 0x4E271D: ???
==18307== by 0x8048BB0: main (in /root/Hari/testapp)
==18307==
==18307==
==18307== 439 (8 direct, 431 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 16
==18307== at 0x4005400: malloc (vg_replace_malloc.c:149)
==18307== by 0x4CC372: ???
==18307== by 0x4E2706: ???
==18307== by 0x8048BB0: main (in /root/Hari/testapp)
==18307==
==18307==
==18307== 24 bytes in 1 blocks are definitely lost in loss record 11 of 16
==18307== at 0x400473F: calloc (vg_replace_malloc.c:279)
==18307== by 0x4DF5E5: ???
==18307== by 0x4DBAFC: ???
==18307== by 0x4F983A: ???
==18307== by 0x4E26A5: ???
==18307== by 0x8048BB0: main (in /root/Hari/testapp)
==18307==
==18307== LEAK SUMMARY:
==18307== definitely lost: 44 bytes in 5 blocks.
==18307== indirectly lost: 455 bytes in 11 blocks.
==18307== possibly lost: 0 bytes in 0 blocks.
==18307== still reachable: 1,054 bytes in 5 blocks.
==18307== suppressed: 0 bytes in 0 blocks.
==18307== Reachable blocks (those to which a pointer was found) are not shown.
==18307== To see them, rerun with: --show-reachable=yes

Logged In: YES
user_id=2045322
Originator: YES

also if you do the cmciconnect again and call CMGetObjectPath, the leak doubles. But if the connection is made once and CMObjectPath gets calls multiple times with the connection, does not enhance the leak.

Logged In: YES
user_id=1550470
Originator: NO

I am able to replicate this, and have fixed some of the leak, but not all. Will investigate more tomorrow.

Logged In: YES
user_id=1550470
Originator: NO

I have attached a patch for this. See if it improves things for you. Patch using -p0 from the root sfcb source directory.
File Added: 1928541-binary_interface_memory_leak_on_CMGetObjectPath.patch

Logged In: YES
user_id=2045322
Originator: YES

Thanks. But am not able to use this patch. Have you patched on 1.2.5. It says malformed patch when i tried to apply using patch -p0 < <patch_name>

Logged In: YES
user_id=1550470
Originator: NO

Sorry about that, Rajib. I've updated the patch file and tested it with 1.2.5.
File Added: 1928541-binary_interface_memory_leak_on_CMGetObjectPath-2.patch

Logged In: YES
user_id=2045322
Originator: YES

chris,

Thanks. I was able to patch it on 1.2.5. But, It causes the Interop provider to die. I am hereby attaching the gdb report below. Also strangely the valgrind shows more leak this time. I am not sure if i am missing something.

gdb report:
-------------

Core was generated by `sfcbd -c /usr/local/etc/sfcb/sfcb.cfg'.
Program terminated with signal 11, Segmentation fault.
#0 0x08ad8510 in ?? ()
(gdb) bt
#0 0x08ad8510 in ?? ()
#1 0x00e57b44 in sfcb_native_release_CMPIValue (type=5632, val=0x8ada16c) at value.c:81
#2 0x00e4b3d3 in __aft_release (array=0x8ad7d68) at array.c:64
#3 0x00e536da in __ift_getObjectPath (instance=0x8ad9cf0, rc=0xb7f64bdc) at instance.c:342
#4 0x00b1039d in initInterOp (broker=0xe8b0f4, ctx=0x8ace970) at interopProvider.c:660
#5 0x00b10c4c in InteropProviderInvokeMethod (mi=0xb12da8, ctx=0x8ace970, rslt=0x8ace120,
ref=0x8ace514, methodName=0x8ace578 "_startup", in=0x8ace584, out=0x8ace490)
at interopProvider.c:1084
#6 0x00e704ff in invokeMethod (hdr=0x8ace4c0, info=0x8ace050, requestor=-5)
at providerDrv.c:1271
#7 0x00e78990 in processProviderInvocationRequestsThread (prms=0x8ac77e8) at providerDrv.c:2468
#8 0x4fd05402 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#9 0x4fc5d2ae in clone () from /lib/i686/nosegneg/libc.so.6

valgrind report:
-----------------

==8299== 28 (4 direct, 24 indirect) bytes in 1 blocks are definitely lost in
loss record 4 of 13
==8299== at 0x4005400: malloc (vg_replace_malloc.c:149)
==8299== by 0x41467A1: ???
==8299== by 0x8048BB7: main (in /root/Hari/testapp)
==8299==
==8299==
==8299== 72 (8 direct, 64 indirect) bytes in 1 blocks are definitely lost in
loss record 7 of 13
==8299== at 0x4005400: malloc (vg_replace_malloc.c:149)
==8299== by 0x4182372: ???
==8299== by 0x414678A: ???
==8299== by 0x8048BB7: main (in /root/Hari/testapp)
==8299==
==8299==
==8299== 16 bytes in 1 blocks are definitely lost in loss record 8 of 13
==8299== at 0x4005400: malloc (vg_replace_malloc.c:149)
==8299== by 0x4F7DE01F: strdup (in /lib/libc-2.5.so)
==8299== by 0x4146758: ???
==8299== by 0x8048BB7: main (in /root/Hari/testapp)
==8299==
==8299==
==8299== 24 bytes in 1 blocks are definitely lost in loss record 10 of 13
==8299== at 0x400473F: calloc (vg_replace_malloc.c:279)
==8299== by 0x41435F5: ???
==8299== by 0x413FB0C: ???
==8299== by 0x415D8BA: ???
==8299== by 0x4146729: ???
==8299== by 0x8048BB7: main (in /root/Hari/testapp)
==8299==
==8299== LEAK SUMMARY:
==8299== definitely lost: 60 bytes in 6 blocks.
==8299== indirectly lost: 88 bytes in 3 blocks.
==8299== possibly lost: 0 bytes in 0 blocks.
==8299== still reachable: 1,054 bytes in 5 blocks.
==8299== suppressed: 0 bytes in 0 blocks.
==8299== Reachable blocks (those to which a pointer was found) are not
shown.
==8299== To see them, rerun with: --show-reachable=yes

Logged In: YES
user_id=1939165
Originator: NO

Rajib,
Can you provide any more information on what is going on when the Interop dies? Any other details you could provide would be very helpful in pinning down a problem and testing the solution.

Logged In: YES
user_id=1550470
Originator: NO

Rajib-
I noticed that this leak does not seem to occur when using the v2 interface (using NewCIMEnv()). The leak reported by this bug is still being investigated, but are you planning on moving to the new interface in the future?

Logged In: YES
user_id=2045322
Originator: YES

Chris,

What is v2 interface? Is this related to sfcc? we have our own cim client which does the binary interaction as well, so i wouldn't be using sfcc. Let me know how can use the new interface without using sfcc.

Logged In: YES
user_id=1550470
Originator: NO

Ah, right, I keep forgetting you're not using sfcc. The way sfcc creates a connection with sfcb has been changed; you can look at the differences between test_ei.c and v2test_ei.c in the TEST directory of sfcc.

I am seeing that using SFCB 1.3 leaks far less memory than SFCB 1.2.5 or the 1.2-cvs branch. Are you seeing the same?

Logged In: YES
user_id=1550470
Originator: NO

Rajib-

Try applying the patch attached to 1893302. In my ei test, the the amount of memory leaked reported by valgrind drops from 4688 to 44.

Logged In: YES
user_id=1939165
Originator: NO

For the v2 test in sfcc, I'm not seeing a memory leak at all. I still see the leak using the v1 test. That leads me to believe that the leak is somewhere in the client code. How are you connecting to sfcb?

Logged In: YES
user_id=1939165
Originator: NO

I found a small leak in the locking management code. I fixed this and made the lock allocation in instance.c use the memory manager. As far as I can tell, this fixes the problem. Let me know if you see the same result.
File Added: 1928541-locking_mem_leak_fix.patch

Fixes support.c problem caused by last patch

Logged In: YES
user_id=1939165
Originator: NO

This patch rolls back a change to memAlloc which caused another problem.
File Added: mem_tracked.patch

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 60 days (the time period specified by
the administrator of this Tracker).