bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnu-libiconv] Address Sanitizer finding in libiconv_open iconv.


From: Bruno Haible
Subject: Re: [bug-gnu-libiconv] Address Sanitizer finding in libiconv_open iconv.c:234
Date: Mon, 06 May 2019 10:02:18 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; )

Hi Jeffrey,

> I'm testing on Fedora 29, x86_64. I'm catching an address sanitizer
> finding in libiconvert-1.16. It was present in 1.15, but I did not
> investigate it. I'm using CFLAGS+=-fsanitize=address and
> CXXFLAGS+=-fsanitize=address (and LDFLAGS+=-fsanitize=address as
> needed).
> ...
> Direct leak of 288 byte(s) in 2 object(s) allocated from:
>     #0 0x7f75d3044c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
>     #1 0x7f75d2e6b1b1 in libiconv_open iconv.c:234

The memory allocation at iconv.c:234 is the one that allocates a
conversion descriptor (iconv_t). If you see this one occur as a
"memory leak", it means that the caller of iconv_open() did not call
iconv_close() on the result.

This might be OK for a test program. See the last paragraph of
https://www.gnu.org/prep/standards/html_node/Memory-Usage.html

Btw, the stack traces produced by the address sanitizer are often
misleading, due to only 3 stack frames. I'd suggest that instead,
you use
  valgrind --tool=memcheck --num-callers=20 --leak-check=yes 
--leak-resolution=high --show-reachable=yes
With 20 stack frames displayed, you get a MUCH better understanding
than with 3 stack frames.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]