Possible String related crash

[Kyle]

Recompiling with TAGLIB_ATOMIC_GCC defined did the trick i think.. i'll
have to do more testing but i havent been able to recreate the crash with
that flag set so far.  I'll send another reply when i know for sure.
 Thanks!


On Sat, Oct 12, 2013 at 1:22 PM, Kyle <gonemad at gmail.com> wrote:

> 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
>



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