[prev in list] [next in list] [prev in thread] [next in thread] 

List:       taglib-devel
Subject:    Re: Remaining leaks found by Valgrind
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2007-01-25 19:37:51
Message-ID: 45B9070F.5010309 () kde ! org
[Download RAW message or body]

Xavier Duret wrote:
> After applying the patches previously sent to the list, there are
> still 3 leaks remaining. Fixing them without breaking binary
> compatibility is above my C++ skills. The leaks are not big but still
> a leak is a leak. Here is what Valgrind reports:
>
>  4 bytes in 1 blocks are still reachable in loss record 1 of 3
>     at 0xFFBC584: operator new(unsigned) (vg_replace_malloc.c:163)
>     by 0xFD7AB2C: __static_initialization_and_destruction_0(int, int)
> (id3v1tag.cpp:50)
>     by 0xFD7ABEC:
> _GLOBAL__I__ZN6TagLib5ID3v13Tag10TagPrivate13stringHandlerE
> (id3v1tag.cpp:240)
>     by 0xFDD0B80: (within /usr/lib/libtag.so.1.4.0)
>     by 0xFD73908: (within /usr/lib/libtag.so.1.4.0)
>     by 0x400DFF4: call_init (in /lib/ld-2.5.so)
>     by 0x400E150: _dl_init (in /lib/ld-2.5.so)
>     by 0x40150F4: _start (in /lib/ld-2.5.so)
>
> It is due to this construct. There is no corresponding "delete".
> const ID3v1::StringHandler *ID3v1::Tag::TagPrivate::stringHandler =
> new StringHandler;
>   

A StringHandler has a size of zero and valgrind usually reports a "loss" 
of zero bytes.  I suppose it's just referring to the pointer.

> The following 2 leaks are due to the fact that the ID3v2 frame factory
> is never deleted:
>
>  8 bytes in 1 blocks are still reachable in loss record 2 of 3
>     at 0xFFBC584: operator new(unsigned) (vg_replace_malloc.c:163)
>     by 0xFD80D5C: TagLib::ID3v2::FrameFactory::FrameFactory()
> (id3v2framefactory.cpp:185)
>     by 0xFD80E6C: TagLib::ID3v2::FrameFactory::instance()
> (id3v2framefactory.cpp:59)
>     by 0xFD761E4: TagLib::MPEG::File::File(char const*, bool,
> TagLib::AudioProperties::ReadStyle) (mpegfile.cpp:227)
>     by 0xFF96810: taglib_file_new_type (tag_c.cpp:63)
>     by 0x10004498: scan_get_taglibinfo (scan-taglib.c:53)
>     by 0x10004E10: main (main.c:84)
>
>  8 bytes in 1 blocks are still reachable in loss record 3 of 3
>     at 0xFFBC584: operator new(unsigned) (vg_replace_malloc.c:163)
>     by 0xFD80E5C: TagLib::ID3v2::FrameFactory::instance()
> (id3v2framefactory.cpp:59)
>     by 0xFD761E4: TagLib::MPEG::File::File(char const*, bool,
> TagLib::AudioProperties::ReadStyle) (mpegfile.cpp:227)
>     by 0xFF96810: taglib_file_new_type (tag_c.cpp:63)
>     by 0x10004498: scan_get_taglibinfo (scan-taglib.c:53)
>     by 0x10004E10: main (main.c:84)

This is just a singleton that I didn't bother to set up a static deleter 
for.  The only case that it would be deleted is when the application 
exits, at which point it doesn't really matter if it leaks.

In effect, neither of these are anything to worry about.

-Scott
_______________________________________________
taglib-devel mailing list
taglib-devel@kde.org
https://mail.kde.org/mailman/listinfo/taglib-devel
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic