#50339 memory leaks from calls to slapi:ch_smprintf
Opened 2 months ago by lkrispen. Modified a month ago

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

2 months ago

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

a month ago

Login to comment on this ticket.

Metadata