Hello,

I ran a little program that loads a DSO against valgrind, and found that:
==11766== 20 bytes in 1 blocks are still reachable in loss record 1 of 1
==11766==    at 0x402422F: calloc (vg_replace_malloc.c:418)
==11766==    by 0x40513C5: _dlerror_run (dlerror.c:142)
==11766==    by 0x4050C80: dlopen@@GLIBC_2.1 (dlopen.c:88)
==11766==    by 0x804CE9B: ds_db_module_load (db_module.c:211)
==11766==    by 0x804AC72: ds_setup_server (server.c:105)
==11766==    by 0x8049596: main (main.c:110)

The offending line in dlopen.c is:
087: # ifdef SHARED
088:   return _dlerror_run (dlopen_doit, &args) ? NULL : args.new;
089: # else
090:   if (_dlerror_run (dlopen_doit, &args))
091:     return NULL;

The offending line in dlerror.c is:
140:       if (result == NULL)
141:     {
142:       result = (struct dl_action_result *) calloc (1, sizeof (*result));
143:       if (result == NULL)
144:         /* We are out of memory.  Since this is no really critical

and _dlerror_run goes on to set the tad on line 151, free the error string (if necessary) on line 155, set some error code on line 164, mark if there is no error on line 168, and finally:
170:   return result->errstring != NULL;

_dlerror_run() stores the dl_action_result by calling __libc_setspecific(key, result) on line 151, so _dlerror_run itself cannot ever free that struct.

So the question becomes: Is free_key_mem in dlerror.c:213 called after valgrind does its analyses, or is this a real memory leak?

All source references are taken from a git clone from 11 June 2011 06:54 GMT.

Regards,
Guus