ThreadX stack overflow when DEBUG enabled

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
grphc_1578046
Level 4
Level 4
10 likes received First like received First like given

While attempting to debug an 802.1X connection to FreeRADIUS I enabled the DEBUG define in an attempt to get more information regarding the problems we were encountering. The result was a stack overflow error. This was picked up in ThreadX.

The application we were running the standard console program included in the SDK. This running under WICED 4.0.0
pastedImage_0.png

The assert stop the program

pastedImage_1.png

I have tried to increase both the ThreadX stack allocation - up to 4K and the app up to 8K with out any change. It seems something is going wrong elsewhere that causes a problem in ThreadX

Thanks

1 Solution

Enlarging Stack to 10K resolves this particular issue

View solution in original post

6 Replies
Anonymous
Not applicable

Are you use mini printf?

0 Likes

no, but as you can see this is not in a routine calling printf

0 Likes
Anonymous
Not applicable

I dont known how closed source treadx checking stack overflow. FreeRtos checking when swithing context. Possible printf calling in other thread.  Maybe parameter TX_THREAD  *thread show which thread overflow stack?

0 Likes

Looking at the data for the thread it seems that the stack has not overflowed

pastedImage_0.png

This is the details of the thread structure in the failed routine - I increased the stack size to 8K in the thread definition but the start and end difference is only 6139
pastedImage_1.png

I do not understand why this is occuring

0 Likes

Enlarging Stack to 10K resolves this particular issue

Anonymous
Not applicable

I would have thought that stack overflow would be trapped by default. It was a painful learning that it is not enabled by default.

Is there much of a performance penalty when it is enabled? (not all of DEBUG, just enabling this one feature of DEBUG)