The loop that looks for the next area to add a message to has a somewhat fatal flaw: it checks for a non-zero area size (which is always set to the physical size of the area rather than the number of message commands stored within it). As a consequence, areas would never get cleaned up once allocated, which lead the kernel to steadily bleed memory if any reasonable level of node monitoring activity was going on. We now check whether or not the area's command count is non-zero instead, and use that as the criteria for selection. Fixes ticket #3518.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29411 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Rene Gollent 2009-03-06 05:45:32 +00:00
parent aa085ffef9
commit 75d1cb286f
2 changed files with 10 additions and 1 deletions

View File

@ -138,6 +138,14 @@ MessagingArea::Size() const
}
// Empty
bool
MessagingArea::IsEmpty() const
{
return fHeader->command_count == 0;
}
// AllocateCommand
void *
MessagingArea::AllocateCommand(uint32 commandWhat, int32 dataSize,
@ -445,7 +453,7 @@ MessagingService::_AllocateCommand(int32 commandWhat, int32 size,
while (fFirstArea != fLastArea) {
area = fFirstArea;
area->Lock();
if (area->Size() != 0) {
if (!area->IsEmpty()) {
area->Unlock();
break;
}

View File

@ -30,6 +30,7 @@ public:
area_id ID() const;
int32 Size() const;
bool IsEmpty() const;
void *AllocateCommand(uint32 commandWhat, int32 dataSize, bool &wasEmpty);
void CommitCommand();