Is there a problem in cTaskResumeAll() ?!

nobody wrote on Wednesday, December 01, 2004:

Dear Contributers,

I noticed (and fixed) a problem in cTaskResumeAll().

Calling this function before any task was initialised may result in a problem. In line 780 (tasks.c) the macro listGET_OWNER_OF_HEAD_ENTRY is called. If the lists were not initialised in a prior task-creation, this macro tries to dereference (?) the uninitialised list-pointer.

Now you could ask, why anyone should call cTaskResumeAll() before the creation of task. This doesn’ t make sense, in fact. But the suspend-all and resume-all funtions are called in the memory-allocation routines. Calling this routines before task-creation makes sense. As memory-allocation is a part of the task-creation I got mysterious hang-ups, when I used suspend/resume-functionality in memory-allocation.

In previous versions the macros portENTER_CRITICAL() and portEXIT_CRITICAL() were used to make memory-routines safe.

Changing line 776 as follows solved the problem for me:
if (( ucSchedulerSuspended == pdFALSE ) &&(usCurrentNumberOfTasks > 0))

With no task created, no actions to put task on any list are performed.

I wonder if anyone noticed this before. Please cross-check this issue and tell me of your experience. Maybe there are other problems in my program.

I use the latest version available on a C167CR. The port to this platform was completed by me. There were some changes in the kernel. I’m in discussion with my tutor, if we could contribute this kernel-version to . I made my changes to the kernel in a way, that enables the user to scale them away via constant-definitions and conditional compilation.

Thanks in advance, Daniel

P.S.: I apologize for my english, as it may be bad.

nobody wrote on Wednesday, December 01, 2004:

Sorry, to post again. My EMail-Adress :


nobody wrote on Wednesday, December 01, 2004:

Sorry for double-posting : EMail-replies to

rtel wrote on Wednesday, December 01, 2004:

Hi Daniel,

I think you are making a good point here.  The memory allocation schemes are intended for the kernel’s use, but there is nothing to say that the user should or shouldn’t use them also.  This is particularly true if you wanted to create a queue for example before the pointer was initialised.

The enter/exit critical functions were replaced by cTaskSuspend/ResumeAll() functions to prevent the interrupts being disabled for the duration of the call.

Your fix is good, at the minor cost of an additional check each time the function is called - which could be frequently.

For now I will update the documentation to say the functions should not be used unless the pointer has previously been initialised and add an entry into the bug list.  I will modify the code for the next release.

Thanks for bringing this to my attention.

As regards to the C167 port - this would be very nice to have, especially if you have some documentation also.  Really as an open source project you should be making this available to the wider community.  You would of coarse be credited with the work.


rtel wrote on Tuesday, December 07, 2004:

Release V2.5.4 has been made available to correct this.