8dac03db35
This does mean that if a custom stack size has been requested which is larger than the default size, we'll end up with a custom stack on the heap instead of on the existing stack. I don't remember exactly why we opted for our custom stack to live on the stack in the fist place. The commit message for the change that introduced it (59601e06d96edb5661a3dd91341d74e16dc6b229) does mention garbage collection as once use-case, but iOS hasn't used GC itself, and a GC's mark-and-sweep would have to include the heap in any case. However, for compatibility we keep the custom stack on the stack if we can, as we pass the default stack size to QVarLengthArray, which covers 99,9999% of apps use anyways (GitHub shows no hits for the QtRunLoopIntegrationStackSize override that would trigger a heap-allocated custom stack). In testing on both simulator and device a custom stack size that results in a heap-allocated custom stack does work, so we should be good in either case. Fixes: QTBUG-135609 Pick-to: 6.8 Change-Id: I86251da005ebca8a1cad5cabd2835e83486b3f8e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit be93c06758260b1e0738ab17a2ecc4ee8f90e87e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>