APE file not destroyed when Fileref set to NULL

[Brett Hoyle]

I find taglib trunk does not destroy TagLib::APE::File when TagLib::FileRef
is set to NULL

 

I am using cmake to generate VS projects and compiling static tag.lib that
is statically linked in to my dll.

 

In the below apeFile will hang around as not NULL but an access violation
will throw if you try to access anything in it.

Eg in the below I open an APE file, followed by an MP3 file. On opening the
mp3 I will get an access violation as apeFile is not NULL.

I have test files for nearly all formats TagLib supports (flac, mp3, mp4,
ogg, mpc, tta, wv, wav, wma, xm) and none of the rest appear to do this.

Note this is simplified pseudo code.

 

TagLib::APE::File *apeFile;
TagLib::MPEG::File *mp3File;
TagLib::FileRef fileRef;

 

 

Bool  GetInfo(LPTSTR szSource)
{
fileRef = TagLib::FileRef(szSource, 1, TagLib::AudioProperties::Fast);

if( !fileRef.isNull() )

{

  if(apeFile = dynamic_cast<TagLib::APE::File *>( fileRef.file() ))
  {
    DoStuff();
  }
  else if(mp3File = dynamic_cast<TagLib::MPEG::File *>( fileRef.file() ))
  {
    DoStuff();
  }
 
  if(apeFile)
  {
    if(apeFile->APETag())   <<Access violation for files after ape that are
not ape file
    {
      DoAPEStuff();
    }
  }
  else if(mp3File)
  {
    if(mp3File->ID3v2Tag())
    {
      DoMP3Stuff();
    }
  }
 
 
  fileRef = TagLib::FileRef();
  return true;
 
}

 

 

The stack look likes this right before the crash:

std::vector<TagLib::Tag *,std::allocator<TagLib::Tag *> >::size() Line 1087

std::vector<TagLib::Tag *,std::allocator<TagLib::Tag *>
>::operator[](unsigned int _Pos) Line 1138

TagLib::TagUnion::tag(int index) Line 96

TagLib::TagUnion::access<TagLib::APE::Tag>(int index, bool create) Line 79

TagLib::APE::File::APETag(bool create) Line 221

CSTDInfoManager::GetInfo(szSource) Line 255

 

 

Should I be setting apeFile to NULL myself?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20130708/e2c2b54b/attachment.html>