Possible String related crash

[Kyle]

Yea I been looking at the ref/deref calls to possibly find a scenario when
it could possibly hit 0 but couldnt find any.  Looking through the
refcounter class i definitely did not compile with TAGLIB_ATOMIC_GCC on so
it looks like its not truly atomic in what im running which might be the
cause.. i'll have to see if the android NDK provides definitions
for __sync_add_and_fetch and __sync_sub_and_fetch

That being said I think I am able to reproduce the crash if i just spawn
1000 threads running my scan code.. so if i can make refcounter atomic i
can give it a try and see if that fixes things

Thanks


On Sat, Oct 12, 2013 at 1:04 PM, Michael Pyne <mpyne at kde.org> wrote:

> 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
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>


-- 
-Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20131012/1e3cb3eb/attachment.html>