Possible String related crash
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...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the taglib-devel