Possible String related crash

Michael Pyne mpyne at kde.org
Sat Oct 12 17:04:35 UTC 2013

On Sat, October 12, 2013 11:41:33 Kyle wrote:
> And I have many more similar but in different parts of taglib.  The only
> common thing I can trace is the use of String::null.  The second trace i
> posted happens in this chunk of code adding 2 static strings
> String ID3v1::genre(int i)
> {
>   if(i >= 0 && i < genresSize)
>     return genres[i] + String::null; // always make a copy
>   return String::null;
> }
> Is there a possibility that String::null is somehow being deleted due to
> some race condition?  I am using taglib in multiple threads at the same
> time.  Any ideas?

I don't know about deleted, but String::null is still just a TagLib::String, 
so that means it acts like any other String.

Specifically what that means is that functions which return String::null to 
fit a String return type may involve invoking the copy-constructor, which uses 
a RefCounter internally.

It looks to me that RefCounter takes care to use atomic operations in a way 
that should be immune to race conditions, but it also has a portable, but racy 
mode of operation that might result in invalid ref counts. If String::null 
ever accidentally gets hit with a 0 ref count due to this it would delete 

Does your Android-compiled TagLib have a real atomic RefCounter class (in 

 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20131012/21d4aa92/attachment.sig>

More information about the taglib-devel mailing list