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