On Mon, Sep 27, 2004 at 11:21:51AM +1000, Phil Homewood wrote: > "raidutil -d0 -e status" leaks a shared memory segment each > time it's invoked, as verified with ipcs(8). Seems to only > be the status command that does it.
I saw this behavior, too (with 0.0.6-4). Not only was the shared memory
segment still allocated after raidutil finished, but the "raideng"
process that raidutil spawns was also left running indefinitely (I had
to kill it by hand).
It turned out that the code path for handling the "-e" option wasn't
cleaning up properly, and so the library that handles the connections
to the "raideng" process didn't shut down the link when it normally
would have (because it thought the link was still in use).
Attached is the one-line patch that seems to have fixed these problems
on my local machine.
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [EMAIL PROTECTED] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
--- deborig-0.0.6-4/raidutils-0.0.6/raidutil/parser.cpp 2004-04-29 05:20:12.000000000 -0500
+++ deblocal-0.0.6-4/raidutils-0.0.6/raidutil/parser.cpp 2008-02-01 14:30:03.556385238 -0500
@@ -730,6 +730,7 @@
{
EventLog *temp = new EventLog (components, eventLogOpts);
cmd_List->add_Item (*temp);
+ delete temp;
}
else
Error_in_Parsing(EventStrings[STR_PARSE_ERR_MUST_SPECIFY_ADDRESS], this_Commands_Text);
@@ -1645,7 +1646,7 @@
temp = new NvramBit (Cache_Stale, params.hba_Num, temp_set);
else
temp = new NvramBit (Cache_Stale, -1, temp_set);
- cmd_List->add_Item (*temp);
+ cmd_List->add_Item (*temp);
delete temp;
}
else if (!strncmp(command_Line, "+cluster", strlen("cluster")))
signature.asc
Description: Digital signature
