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

[maitai at virtual-winds.org]

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