Hi! I noticed something odd in my application today. I wrote some code that called vEventGroupDelete, and it crashed. I discovered this is why: my heap implementation uses a mutex (it seemed like an obvious idea at the time) as a heap lock (I use the Newlib malloc/free functions with _malloclock and _mallocunlock implemented on top of xSemaphoreTakeRecursive and xSemaphoreGiveRecursive respectively). vEventGroupDelete, however, calls vPortFree with the scheduler disabled, which of course fails—you can’t go to sleep to take a semaphore while the scheduler is disabled!

I notice that heap_3 in MemMang, the closest example code, suspends the scheduler while accessing the heap rather than using a mutex. However, I also noticed that the other basic synchronization primitive, the queue, does NOT try to access the heap with the scheduler disabled in vQueueDelete.

Thus my question: is this supposed to work? Is it a bug, meaning that vEventGroupDelete ought to be calling vPortFree after xTaskResumeAll? Or is this not a bug, and vPortMalloc/vPortFree must be safe to call with the scheduler disabled?

It is a usage scenario that doesn't exists is the official code base, so I would not say it was supposed to work, but equally we want the code to be as easy to use with the widest set of scenarios as possible, so I would also say it is not supposed to not work. We will take a look and see what can be done.

Regards.