MQX Software SolutionsのトピックRe: _task_restart() frees and corrupts stack

_task_restart() frees and corrupts stack

kkramb — Fri, 24 Feb 2012 23:15:42 GMT

I'm using MQX 3.8 with Code Warrior 10.2 for a ColdFire MCF52258 project.

The MQX documentation says that _task_restart() is suppossed to restart the specified task with the same stack. In my application, _task_restart() causes the specified task's stack to be freed. The task does restart using a stack area near, but no exactly in the original location. And since the memory is free it eventually gets allocated to other purposes, which causes the task's stack to become corrupted.

I have started to dig into the MQX code. The _task_restart_func() routine seems to intentionally free the task's stack. Then it attempts to rebuild the stack. But it seems to calculate a size and location that is slightly different from the original. And I don't see yet where it actually attempts to reallocate the memory.

Is this a problem with MQX or may I have done something wrong at a higher level? If it's a problem with MQX has anyone already developed a fix?

Thanks,

-- Kevin

Re: _task_restart() frees and corrupts stack

kkramb — Thu, 01 Mar 2012 05:55:55 GMT

I've figured out my problem with _task_restart(). I was using MXQ v3.8 beta 2 and this was a bug in the beta. But it has been fixed in the official release of MXQ v3.8. Since upgrading MXQ to the official release, _task_restart() now calculates the correct size and location of the stack and it does not free the stack*.

* MQX_ALLOW_TYPED_MEMORY and MQX_CHECK_MEMORY_ALLOCATION_ERRORS must be defined as 1 in order for _task_restart() to handle the stack correctly. This is the default behavior in mqx_cnfg.h but if you define either as 0 in your user_config.h then _task_restart() will free the stack, which will lead to eventual stack corruption.

Re: _task_restart() frees and corrupts stack

c0170 — Thu, 01 Mar 2012 17:38:32 GMT

Hi ÂµManaged,

thanks for providing an explanation how you solved the problem, it might help others !

Regards,

MartinK