#50339 memory leaks from calls to slapi:ch_smprintf
Closed: wontfix 4 years ago by mreynolds. Opened 5 years ago by lkrispen.

when running basic tests with an ASAN build it reported leaks like:

 Indirect leak of 69 byte(s) in 1 object(s) allocated from:
     #0 0x7f0ea468c088 in __interceptor_realloc (/lib64/libasan.so.5+0xef088)
     #1 0x7f0ea175c1f2 in GrowStuff ../../.././nspr/pr/src/io/prprf.c:1131
     #2 0x6030003695df  (<unknown module>)

 Indirect leak of 67 byte(s) in 1 object(s) allocated from:
     #0 0x7f0ea468c088 in __interceptor_realloc (/lib64/libasan.so.5+0xef088)
     #1 0x7f0ea175c1f2 in GrowStuff ../../.././nspr/pr/src/io/prprf.c:1131
     #2 0x6030003a695f  (<unknown module>)

 Indirect leak of 64 byte(s) in 1 object(s) allocated from:
     #0 0x7f0ea468c088 in __interceptor_realloc (/lib64/libasan.so.5+0xef088)
     #1 0x7f0ea175c1f2 in GrowStuff ../../.././nspr/pr/src/io/prprf.c:1131
     #2 0x603000398b2f  (<unknown module>)

valgrind didn't report these leaks at all.

When debugging the calls to GrowStuff() I noticed that they are from slapi_ch_smprintf() when the format string is parsed and memory reallocated.

I have no idea why the stacks are truncated or how to get full stacks. But I looked into the slapi_ch_smprintf() calls of my patch and noticed one call where the result was not freed. Fixing this reduced the reported leaks from asan, so this confirms the theory.

This means we would have to investigate the calls to slapi_ch_smprintf() :-(


I think this happens if symbols for a module are not installed?

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

4 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.1

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3398

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata