[VxW] Fwd: memPartFree Error??

[Gobinath.A]

Hi,
We have encountered the following error in vxworks :

"0x58ac58 (tmsShutdownTask): memPartFree: invalid block 0xffbd28 in partition 0xfebef0"

while terminating the tasks reading and writing to the sockets. We haven't called the function memPartFree explicitly in our program. We avoided using the taskDelete in our code. But the tasks are terminated after checking the state of the socket. The tasks terminates as we expexted but still driving this error.

We are not clear with reason for this problem. Please give a valuable solution. Please let us know the other root causes that normally drives this error.

Thanks,
Gobinath

[Joe Durusau]

This is a guess, but this problem is most often caused
by stack overflow. Check stack usage.

Speaking only for myself,

Joe Durusau

[Narendra Hadke]

It may be because same memory location is getting freed twice.

For similar query I replied earlier,

>Do you see, error similar to this
>"<address 1> (<taskn>): memPartFree: invalid block <address2> in
partition <address3>"
>on console ?

>In vxWorks land, freeing same memory location twice will suspend the task
>which has called free() second time. This will cause exception similar to
>one above suspending the task.
>I experienced this problem once. Fixed by making sure memory is freed
>exactly once.( kernel :Wind 2.5 )
>Thanks,
>Narendra Hadke

At 11:48 AM 3/4/2004 +0530, Gobinath.A wrote:
>Hi,
>We have encountered the following error in vxworks :
>
>"0x58ac58 (tmsShutdownTask): memPartFree: invalid block 0xffbd28 in
>partition 0xfebef0"
>
>while terminating the tasks reading and writing to the sockets. We haven't
>called the function memPartFree explicitly in our program. We avoided
>using the taskDelete in our code. But the tasks are terminated after
>checking the state of the socket. The tasks terminates as we expexted but
>still driving this error.
>
>We are not clear with reason for this problem. Please give a valuable
>solution. Please let us know the other root causes that normally drives
>this error.
>
>Thanks,
>Gobinath

>_______________________________________________
>VxWorks Users Group mailing list
>VxWe...@lbl.gov
>http://www-csg.lbl.gov/vxworks/

[Lawrence T. Hoff]

We had the same problem a few years ago. It turned out to
be a bug in the VxWorks "memShow.o" library. I'm surprised that
WRS has not fixed it yet.

The problem is in a function which "walks" the heap to
determine how much space is allocated. The function does not
properly lock the heap, so it can "walk off the end of a pier"
if some other task manipulates the heap in the middle of the
"walk". When it walks off the end of the pier, it decides that
the heap must be corrupted, and tries to rectify the situation
by removing what it thinks is the offending block (actually making
things worse), and prints the message that you see.

This can only happen if you call "memShow()", or
"memPartInfoGet()" from a task context which can be preempted.
I *think* if you always call "taskLock()" or "intLock()"
before calling either of those functions then you are protected.
I also *think* that because the heap uses a MUTEX with priority
inversion protection that you cannot rely on priority alone
to provide protection against being preempted.

Our solution was to write our own memPartInfoGet() which
has proper heap locking in it.

HTH -- Larry

[Lawrence T. Hoff]