[Android-development] Qt5.4.1/Android 5, pb multi-threading

maitai at virtual-winds.org maitai at virtual-winds.org
Thu Feb 26 19:33:51 CET 2015 

Hello,

Did this patch make it to 5.4.1 finally? If yes I can send my user a new 
apk to test again just in case it fixes my/his issue with android 5.

Thanks
Philippe

Le 18-02-2015 17:39, maitai at virtual-winds.org a écrit :
> Could be... let's hope it's pushed in final 5.4.1
> 
> For the time being I ended up with a test on api level and if >19 I
> don't use QtConcurrent for this particular calculation. Note that this
> program uses QtConcurrent in various other places (6 in total), and 
> just
> one is blocking, the biggest as far as stack size is concerned but also
> probably the one that takes longer.
> 
> I have created QTBUG-44543 for that.
> 
> Thanks for your help and concern
> 
> Philippe.
> 
> Le 18-02-2015 15:42, Robert Iakobashvili a écrit :
>> Philippe,
>> Could it be something related to your issue
>> if conditional variable are used somewhere in QtConcurrent?
>> 
>> https://codereview.qt-project.org/#/c/105855/
>> Regards,
>> Robert
>> 
>> 
>> On Wed, Feb 18, 2015 at 2:31 PM, Robert Iakobashvili
>> <coroberti at gmail.com> wrote:
>>> Philippe,
>>> We are using QThread-s instead.
>>> 
>>> So, we are running several threads
>>> with the number eq or a bit above the num of cores
>>> and we are making our custom barrier to
>>> wait for them to exit.
>>> 
>>> In meanwhile, user gets a progress dialog.
>>> 
>>> Regards,
>>> Robert
>>> 
>>> 
>>> On Wed, Feb 18, 2015 at 2:15 PM,  <maitai at virtual-winds.org> wrote:
>>>> Thanks Robert,
>>>> 
>>>> It creates on the stack quite a lot of double/int/QPolygonF but
>>>> nothing
>>>> really big like images or such. In fact what is strange is that it
>>>> works
>>>> for let's say 30 passes and then with nothing particular it hangs.
>>>> The
>>>> routine used in blockinMap always hits return, but QtConcurrent is
>>>> never
>>>> notified, as it seems. I've tried to limit the number of variables 
>>>> to
>>>> treat to the IdealThreadCount value or to not treat lists of values
>>>> but
>>>> values directly same problem.
>>>> 
>>>> If instead of calling blockingMap(list<list>) I loop on the lists to
>>>> treat each value in turn in the main thread it works, so it's really
>>>> something related to QtConcurrent and lollipop.
>>>> 
>>>> I'll use the few time remaining with the device to try to build a
>>>> simple
>>>> example that reproduces the issue....
>>>> 
>>>> Philippe
>>>> 
>>>> Le 18-02-2015 12:22, Robert Iakobashvili a écrit :
>>>>> Philippe,
>>>>> If you think that this is something dealing with thread stack
>>>>> size, are there any large objects you can allocate on heap
>>>>> instead of stack?
>>>>> 
>>>>> jm2c
>>>>> 
>>>>> Take care!
>>>>> Robert
>>>>> 
>>>>> 
>>>>> On Wed, Feb 18, 2015 at 1:16 PM,  <maitai at virtual-winds.org> wrote:
>>>>>> Back on this problem:
>>>>>> 
>>>>>> I finally have access to this device for some hours. I can see the
>>>>>> following:
>>>>>> 
>>>>>> I call QtConcurrent::blockingMap() with a list of value, and from
>>>>>> time
>>>>>> to time, blockingMap() never returns and the program hang there
>>>>>> with 0
>>>>>> cpu usage, and no particular message in logcat.
>>>>>> 
>>>>>> I have modify my routine called by blockingMap in order to check
>>>>>> that
>>>>>> every things finished, and I get this output in the console
>>>>>> 
>>>>>> ....... (many passes before it hangs)
>>>>>> 
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): before qtconcurrent
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 2
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 1
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 3
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 3
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 0
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 1
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 2
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 0
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): after qtconcurrent
>>>>>> <--- all good
>>>>>> 
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): before qtconcurrent
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 0
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 1
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 2
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): start treating list 
>>>>>> number
>>>>>> 3
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 1
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 0
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 3
>>>>>> W/libqtVlm.so(26873): (null):0 ((null)): finished treating list
>>>>>> number
>>>>>> 2
>>>>>> 
>>>>>> ... and nothing more, it stays there forever.
>>>>>> 
>>>>>> This programs works perfectly under Android 4.x, Windows, Linux,
>>>>>> MacOs,
>>>>>> etc. I only have this issue on Android 5.0.1 (lollipop), and I now
>>>>>> have
>>>>>> 2 users complaining (my only 2 users using lollipop).
>>>>>> 
>>>>>> I still have around 2 hours with the device the user lend me... so
>>>>>> if
>>>>>> anyone has any idea what else I could test/verify/etc before I 
>>>>>> post
>>>>>> a
>>>>>> bug to qt.. :)
>>>>>> 
>>>>>> Thanks
>>>>>> Philippe Lelong
>>>>>> 
>>>>>> 
>>>>>> Le 13-02-2015 14:11, maitai at virtual-winds.org a écrit :
>>>>>>> Hello,
>>>>>>> 
>>>>>>> I have one user who just upgraded his Galaxy S5 to android 5
>>>>>>> 
>>>>>>> Since then, one calculation involving heavy multiprocessing 
>>>>>>> (using
>>>>>>> only QtConcurrent::blockingMapped()) just get locks forever, as 
>>>>>>> if
>>>>>>> a
>>>>>>> thread is never returning. There is an option in the app to force
>>>>>>> mono-processing and in that case it's all ok, hopefully.
>>>>>>> 
>>>>>>> Before upgrade he was running android 4.4.4, and no such problems
>>>>>>> of
>>>>>>> course.
>>>>>>> 
>>>>>>> This is done with latest 5.4.1 snapshot, compiled with latest
>>>>>>> JDK/NDK/SDK/GCC/etc.
>>>>>>> 
>>>>>>> Does this says something to anyone?
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Philippe Lelong
>>>>>> _______________________________________________
>>>>>> Android-development mailing list
>>>>>> Android-development at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/android-development
>>>> _______________________________________________
>>>> Android-development mailing list
>>>> Android-development at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/android-development
> _______________________________________________
> Android-development mailing list
> Android-development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/android-development

More information about the Android-development mailing list