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

[maitai at virtual-winds.org]

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