Increasing CHIP_TASK_STACK_SIZE from 4096 -> 5120

[mgarb1]

Problem

What is being fixed? Examples:-

• Fix crash when provisionen a Thread devices on TI platform due to low memory

Change overview

Increasing CHIP_TASK_STACK_SIZE from 4096 -> 5120

Testing

Tested on physical device and provisioning do not get memory error anymore.

[CLAassistant]

All committers have signed the CLA.

[andy31415]

The need for such a large stack is somewhat concerning.

[bzbarsky-apple]

Should this be changed in this central location, or for this specific platform? Other platforms already override this...

[bzbarsky-apple]

This should be changed for the relevant platform, not globally.

[mgarb1]

@bzbarsky-apple The stack increase is now done on platform level instead og globally. Tested and is working. Please see 12f48da

[andy31415]

This should be changed for the relevant platform, not globally.

I had a similar thought, however I also wondered what would make TI special here - I would have assumed that the chip stack is quite low level and its stack usage should not differ greatly between platforms.

@mgarb1 Do we know what code path causes the overflow? That may help us in determining if this is really platform-specific or if this is just the platform that found it (and others happily corrupt memory).

[mgarb1]

@andy31415 The stack increase is done on platform level instead of globally. Tested and is working. Please see 12f48da

@srickardti @andy31415 is asking "Do we know what code path causes the overflow? That may help us in determining if this is really platform-specific or if this is just the platform that found it (and others happily corrupt memory)." can you answer this?

[srickardti]

@mgarb1 @andy31415 I haven't investigated this specifically, but we could add a watchpoint at the top of the stack. The issue I've found in debugging these things is the stack check feature of the kernel is done in the idle loop or in a context switch, not when it actually pops the stack.

I have noticed that other platforms have very large callstacks, larger than this.

In the past I've seen these issues caused by log messages. snprintf has no problem allocating hundreds of bytes on the stack to build its message. If the stack is filled with space characters (0x20) there's a good chance snprintf was using that as scratch space.