Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uxTaskGetStackHighWaterMark() return type too small #27

Closed
Floessie opened this issue Dec 21, 2017 · 4 comments · Fixed by #29
Closed

uxTaskGetStackHighWaterMark() return type too small #27

Floessie opened this issue Dec 21, 2017 · 4 comments · Fixed by #29
Assignees
Labels

Comments

@Floessie
Copy link
Contributor

Hi Phillip,

I just stumbled upon the return type of uxTaskGetStackHighWaterMark(): It's UBaseType_t, and that is defined as unsigned char in this port. The stack size is provided as unsigned short words to xTaskCreate(), thus theoretically 64kB are possible here.

Wouldn't it be better to patch tasks.c to make it return unsigned short instead of UBaseType_t, as prvTaskCheckFreeStackSpace() correctly returns a uint16_t? Otherwise uxTaskGetStackHighWaterMark() will return a misguiding value.

Thanks,
Flössie

@feilipu
Copy link
Owner

feilipu commented Jan 1, 2018

@Floessie,

that seems correct.

In the current v10 version the stack size type is configurable configSTACK_DEPTH_TYPE and is defined here as uint16t. So the documentation is slightly out of date.

I think that @RichardBarry or @aggarg is still in the process of sorting out a migration in this direction, and so it is something that should interest him. You might want to raise it on the freeRTOS.org web site.

I'll leave this open and see what happens in the first bug-fix release of v10.

@feilipu
Copy link
Owner

feilipu commented Jan 3, 2018

I found two more references, and added the backwards compatibility option discussed.

(also reverted the EIND references. still can't understand why the #definition was not being expanded in the macro. anyway... whatever).

@RichardBarry
Copy link

Not been following the EIND discussion recently, but from your last comment "still can't understand why the #definition was not being expanded in the macro" I'm surmising the EIND was being #defined to something that was not being pre processed as expected. If that is the case, and if the macro was in an assembler file with a .s extension, then try changing the extension to .S (upper case) if it is to be preprocessed.

@feilipu
Copy link
Owner

feilipu commented Jan 3, 2018

Off issue topic, but I was trying to prettify the portSAVE_CONTEXT macro by using __EIND__ and a define for this in portmacro.h. So, there were no .s or .S files involved.

Anyway, it was just to make things pretty, so I reverted it to use the 0x3C value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants