#1299 Memory leak in "getSfcbUuid"

[Nicholas Bofferding]

During a logevity testing exercise, ran SFCB for a long
time with SLP enabled. After a pretty good length of
time, I killed the daemon.

*** Valgrind noted that the "ServerProvider" process had a large amount of memory still allocated when the
process terminated. In this case, 58,644 bytes were dedicated to storing duplicate UUIDs.

==19115== 58,644 bytes in 1,086 blocks are definitely lost in loss record 32 of 34
==19115== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==19115== by 0x40BBAD9: getSfcbUuid (interopServerProvider.c:82)
==19115== by 0x40BBCED: ComMechProviderEnumInstances (interopServerProvider.c:470)
==19115== by 0x40BDD90: ServerProviderEnumInstances (interopServerProvider.c:576)
==19115== by 0x4097B1E: enumInstances (providerDrv.c:1513)
==19115== by 0x409B8DF: processProviderInvocationRequestsThread (providerDrv.c:2468)
==19115== by 0x6C543A: start_thread (in /lib/libpthread-2.5.so)
==19115== by 0x61CFDD: clone (in /lib/libc-2.5.so)

*** I looked at the source and realized that SFCB
mallocs a new UUID (line 82) during any query where the UUID file does not exist(which is the case in our implementation). Normally, in the case where UUID file does exist, SFCB performs the allocation once (line 71) and assigns the result to a static variable.

56 static char *getSfcbUuid()
57 {
58 static char *uuid=NULL;
59
60 if (uuid==NULL) {
61 FILE *uuidFile;
62 char *fn=alloca(strlen(SFCB_STATEDIR)+strlen("/uuid")+8);
63 strcpy(fn,SFCB_STATEDIR);
64 strcat(fn,"/uuid");
65 uuidFile=fopen(fn,"r");
66 if (uuidFile) {
67 char u[512];
68 if (fgets(u,512,uuidFile)!=NULL) {
69 int l=strlen(u);
70 if (l) u[l-1]=0;
71 uuid=(char*)malloc(l+32);
72 strcpy(uuid,"sfcb:");
73 strcat(uuid,u);
74 fclose(uuidFile);
75 return uuid;
76 }
77 fclose(uuidFile);
78 }
79 else {
80 char hostName[512];
81 gethostname(hostName,511);
82 char *u=(char*)malloc(strlen(hostName)+32); <====== MALLOC
83 strcpy(u,"sfcb:NO-UUID-FILE-");
84 strcat(u,hostName);
85 return u;
86 }
87 }
88 return uuid;
89 }

*** Configuration details:

- SFCB v1.2.5 running on x86 platform, HTTPS enabled.

*** To reproduce

- Query for the CIM_ObjectManagerCommunicationMechanism instance a
number of times after starting SFCB under valgrind:

valgrind --trace-children=yes --leak-check=full --show-reachable=yes sfcbd

Then:

wbemcli -noverify ei https://127.0.0.1:5989/root/interop:CIM_ObjectManagerCommunicationMechanism

Quit SFCB and valgrind will dump out a trace which
confirms the leak (wasted memory grows linearly with
the number of queries).

[Michael Chase-Salerno]

Comitted patch

[Michael Chase-Salerno]

Logged In: YES
user_id=99742
Originator: NO

In order to prevent the repeated mallocs, preserve the non-file derived uuid value in a static and check if it's been saved before reallocating it. This maintains the behavior that if the file appears, it will be discovered on the next time through.
File Added: 2039216.patch

[SourceForge Robot]

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