VDK::MallocBlock API returns invalid Block pointer Error(kInvalidBlockPointer)

Hi,

The error is raised by VDK::MallocBlock() when there are no free blocks remaining in the specified memory pool. VDK::MallocBlock() is used internally by VDK::CreateMessage() to allocate message objects from a private(reserved) memory pool.

If you haven't created any memory pools of your own then the only way that a kErrorMallocBlock error can arise is if the limit on the number of messages is reached.

If the data structures of a memory pool are illegally overwritten then it would be possible for the memory pool to incorrectly appear full, in which case this error would be raised. This also applies to the private memory pool which is used for message objects.

Messages are allocated from a private memory pool. Its size is configured by the "Max number of messages" setting in the kernel tab. If VDK::CreateMessage() is called after this limit has been reached. The reason that the error results in a kernel panic is that it goes first to the thread's error function, and if it is not handled there then it goes to the system error handler which raises the panic.

It may be that you simply need to increase the "Max number of messages" setting in the kernel tab. However, if it is not possible to set a definite ceiling on the number of messages that your application needs then some re-design may be required in order to avoid the possibility of runtime errors.

One possibility is to pre-allocate all messages by creating them during application startup, and then recycle then by returning them to the sender instead of destroying them.

Another is to use a counting semaphore to regulate the creation of messages. The semaphore sound be have its initial and max values set to be the same as the max number of messages. VDK:endSemaphore() should be called immediately before each VDK::CreateMessage() and VDK:ostMessage immediately after each VDK:estroyMessage().

Regards,
Nishanthi.V

Hi Nishanthi,

We have gone through the disassembly instructions of VDK::MallocBlock() API and could not see locking mechanism used  inside the API like we seen standard malloc() function. We wanted to confirm that whether VDK::MallocBlock() API is thread safe?.  Following is our VDSP and VDK kernel version used in our project

Regards,

Hareesha

Hi,

Yes, all VDK API functions are thread safe.

We would recommend you to refer through the below linked EE-note for more information.
www.analog.com/.../EE-303.pdf

Also, below linked VDK user guide gives you a overview of VDK kernel.
www.analog.com/.../50_vdk_mn_rev_3.5.pdf

Had you tried with the latest VisualdSP++ 5.1.2 which is in the below link.
download.analog.com/.../VisualDSP 5.1.2.exe

Regards,
Nishanthi.V

Hi Hareesha,

Also, we would request you to try setting the priority of the thread which is containing the VDK_MallocBlock call to the lowest priority and let us know how you are getting on.

Unfortunately, We will not provide internal kernel data structures and as this was a legacy product.

In-order to find out whether is the problem with your custom board, would you be able to try the code on our EZ-KIT? This will be helpful for us to isolate the issue further.

Regards,
Nishanthi.V

Hi Nishanthi,

Thanks for the quick reply.

We have created Pool of size 640 bytes(64*10) using VDK_CreatePool() API , However it actually creates 48 bytes extra to store Pool details like Pool Start Address, size of the block etc. This we have confirmed by understanding disassembly source code of the VDK_MallocBlock() API 

VDK_MallocBlock()  API  stores last free block address in memory location , which is a part of 48 bytes that is allocated during Pool creation. In normal scenario value of this memory location either 0 or last free block address, However on some scenario this memory location is written with junk value and same value has been returned as block address on consecutive block allocation using VDK_MallocBlock() API . This will be considered as out of range address when block is freed using VDK:;FreeBlock() APi and resulting into kernel panic. 

Can you please explain on which scenario memory location,which holds the free block address will be overwritten?

Thanks in advance.

Regards,

Hareesha

Hi,

it may help to know that we have made the VDK sources for SHARC and Blackfin available via Github.

The sources can be found here, the top level README.md contains details on licensing and building:

https://github.com/analogdevicesinc/VDK

It may be possible to add individual files, such as the VDK heap support to your project and build the project to use those versions in order to assist in debugging.

Typically we only see corruption in the pool in the following cases:

i. User application pointers incorrectly reference header data in the pool resulting in corruption

ii. Pool blocks used in one thread after being free'd by another thread

Essentially it's all the same cases that can occur in a normal C malloc() free() scenario.

Regards,

Dave

Hi,

it may help to know that we have made the VDK sources for SHARC and Blackfin available via Github.

The sources can be found here, the top level README.md contains details on licensing and building:

https://github.com/analogdevicesinc/VDK

It may be possible to add individual files, such as the VDK heap support to your project and build the project to use those versions in order to assist in debugging.

Typically we only see corruption in the pool in the following cases:

i. User application pointers incorrectly reference header data in the pool resulting in corruption

ii. Pool blocks used in one thread after being free'd by another thread

Essentially it's all the same cases that can occur in a normal C malloc() free() scenario.

Regards,

Dave