possible memory leak using TROE

[cfreyfh]

Hi there,

we are storing a lot of timeseries data using the TROE feature. When running the context broker for longer times, the memory consumption gets higher and highter. So I just did a debug run using valgrind.

If I look at the output there are several places where it complains about possible losses but one realy points out:

==1== 13,303,808 bytes in 14 blocks are definitely lost in loss record 2,628 of 2,628
==1==    at 0x4C40B77: realloc (vg_replace_malloc.c:1690)
==1==    by 0x505037: pgAppend(PgAppendBuffer*, char const*, int) (in /usr/bin/orionld)
==1==    by 0x50677C: pgAttributeAppend(PgAppendBuffer*, char const*, char*, char const*, char const*, char*, char*, bool, char*, char*, KjNode*) (in /usr/bin/orionld)
==1==    by 0x506058: pgAttributeBuild(PgAppendBuffer*, char const*, char const*, KjNode*, PgAppendBuffer*) (in /usr/bin/orionld)
==1==    by 0x507001: pgAttributesBuild(PgAppendBuffer*, KjNode*, char*, char const*, PgAppendBuffer*) (in /usr/bin/orionld)
==1==    by 0x50249D: troePostBatchUpsert() (in /usr/bin/orionld)
==1==    by 0x49324B: requestCompleted(void*, MHD_Connection*, void**, MHD_RequestTerminationCode) (in /usr/bin/orionld)
==1==    by 0xBD8F604: connection_reset (connection.c:4349)
==1==    by 0xBD8F604: MHD_connection_handle_idle (connection.c:4832)
==1==    by 0xBD91258: call_handlers (daemon.c:1234)
==1==    by 0xBD96277: MHD_epoll (daemon.c:5149)
==1==    by 0xBD96F14: MHD_polling_thread (daemon.c:5386)
==1==    by 0x7CDA1C9: start_thread (in /usr/lib64/libpthread-2.28.so)

When I look at the function troePostBatchUpsert() I saw, that at the beginning of the function the memory for the pointers where to store the INSERT/UPDATE strings is allocated

context.Orion-LD/src/lib/orionld/troe/troePostBatchUpsert.cpp

Line 82 in df37d3f

pgAppendInit(&entities, 4*1024); // 4k - will be reallocated if necessary

, then the string is generated but at the end there is no free of the tree buffers

  PgAppendBuffer  entities;
  PgAppendBuffer  attributes;
  PgAppendBuffer  subAttributes;

Could that be a memory leak?

Greetings
Carsten

[cfreyfh]

OK, I just saw that you are using a library managing the memory allocation:

context.Orion-LD/src/lib/orionld/troe/pgAppendInit.cpp

Line 42 in e773a36

pgBufP->buf = (char*) kaAlloc(&orionldState.kalloc, initSize);

but isn't it then a problem if you use a realloc or a maloc on the same pointer because where would the memory be released that the pointer was pointing before?

context.Orion-LD/src/lib/orionld/troe/pgAppend.cpp

Line 69 in e773a36

pgBufP->buf = (char*) malloc(pgBufP->bufSize);

Shouldn't be there something like
free(oldBuffer);
after copying its content to the new allocated memory?