Small memory leak in kernel TOOLSDS/SALOMEDS_Tool.cxx

SALOMEDS_Tool.hxx has:

typedef std::vector<std::string> ListOfFiles;

and in SALOMEDS_Tool.cxx: PutStreamToFiles:

  ListOfFiles aFiles;
 ...
  char *aFileName = new char[aFileNameSize]; 
 ...
  aFiles.push_back(CORBA::string_dup(aFileName));
  delete[] aFileName;

The CORBA::string_dup, without a matching CORBA::string_free, obviously leaks memory.
This can be trivially fixed by just removing the CORBA::string_dup.
Bonus points for replacing aFileName with a std::string and using std::move.

How can/should patches be submitted?

Hello

There is no leak here as CORBA manages it-self memory chunks that are returned from a function. Try using valgrind to see that everything is OK here

Best regards

CORBA::string_dup returns a plain char*, not a managed object (String_var).

omniORB source code (/omniORB4/stringtypes.h):

class _CORBA_String_helper {
static inline char* dup(const char* s) { 
  int   l = (int)strlen(s);
  char* r = alloc(l);
  if (r) {
    strcpy(r, s);
    return r;
  }
  return 0;
}
// As CORBA::string_dup().

As far as I see you suggest adding CORBA::string_free as follows
aFiles.push_back(CORBA::string_dup(aFileName));
CORBA::string_free( aFiles.back())

But what aFiles will return then, as we destroy its content?

No. Just remove the CORBA::string_dup call.

std::vector<std::string>::push_back(...) calls the std::string constructor and copies the char.

You suggestion is double wrong, it still leaks the temporary char array, but deletes a std::string owned by the vector.

I would submit a patch, but this seems to be impossible here.

Indeed, now I see you are right. I’ll push your fix. OK?
Thank you.

Best regards