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
itself.
Does your Android-compiled TagLib have a real atomic RefCounter class (in
taglib/toolkit/trefcounter.{h,cpp})?
Regards,
- 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