gt netsocket tcp - increases threads' stack size

[VeijoPesonen]

Description

Greentea netsocket tcp test cases - used thread stack size was insufficient for debug profile.
Also insufficient thread stack size with NUCLEO_F401RE+IDW01M1 - please see issue ARMmbed/wifi-x-nucleo-idw01m1#17

Test case timeout value increased because demanded by the new ARMmbed/esp8266-driver#83

Patch (commit) 24905f5 provided by @betzw.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

[VeijoPesonen]

@betzw, @juhaylinen - includes everything required by ARMmbed/wifi-x-nucleo-idw01m1#17? @kjbracey-arm, @SeppoTakalo please review.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3110
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8132/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2717
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8132/

[mbed-ci]

Test : FAILURE

Build number : 2900
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8132/2900

[VeijoPesonen]

Hmm, I claim this one:

BUILD/tests/ARCH_PRO/GCC_ARM/TESTS/netsocket/tcp/tcp.bin , TCPSOCKET_ECHOTEST_NONBLOCK - might be that the stack size got too big

Other failures, not caused by these test case changes:

BUILD/tests/LPC546XX/GCC_ARM/TESTS/mbed_drivers/crc/crc.bin , tests-mbed_drivers-crc
BUILD/tests/LPC546XX/ARM/TESTS/netsocket/dns/dns.bin , tests-netsocket-dns
BUILD/tests/LPC546XX/ARM/TESTS/netsocket/dns/dns.bin , features-frameworks-utest-tests-unit_tests-case_control_async
BUILD/tests/LPC546XX/IAR/TESTS/mbed_hal/us_ticker/us_ticker.bin , tests-mbed_hal-us_ticker

BUILD/tests/NUCLEO_F746ZG/ARM/TESTS/mbed_drivers/lp_ticker/lp_ticker.bin , tests-mbed_drivers-lp_ticker

[VeijoPesonen]

@betzw could you check if 2048B as stack size is sufficient with NUCLEO_F401RE? It seems to be enough for debug profile with K64F.

[betzw]

Well, I will check, but what I can already say is that I know of some demo application (e.g. mbed_cloud_client) where a stack size of 4K was necessary!
Btw, I think that stack size is less dependent on the board/chip but typically much more on the application you run. It might be that a stack overflow on the NUCLEO_F401RE leads more easily to memory corruption than on other platforms, which mostly depends on the memory layout (i.e. linker script) for a specific platform.

[VeijoPesonen]

The stack size we are talking here is only for the threads created specifically in these netsocket tcp cases. Doesn't have systemwide affect.

[VeijoPesonen]

@betzw have you had time yet to check this?

[betzw]

Not yet.

[betzw]

netsocket-tcp test run on my side also with 2K of stack.

[VeijoPesonen]

@betzw @SeppoTakalo @cmonr please review and and once it's done - needs: CI

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3179
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8132/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2778
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8132/

[mbed-ci]

Test : SUCCESS

Build number : 2984
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8132/2984