This is for Dave Roth and company. I noticed this memory leak in Win32::Perms. I've since found this old posting from last June. I believe is the same issue I'm facing.
Is there any chance this may be fixed in the near future? :-) Thanks Kirk W. Batzer [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Friday, June 14, 2002 5:05 PM > To: [EMAIL PROTECTED] > Subject: RE: Recursive Win32::Perms memory leak > > > If Mr. Roth is around, perhaps, he could shed some light on > the issue? (I promise I'll buy your second book 8^] ) > > -----Original Message----- > From: Hornyak, Douglas > Sent: Thursday, June 13, 2002 11:03 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Recursive Win32::Perms memory leak > > > I just replaced the Win32::Perms call with > Win32::FileSecurity::Get with no memory issues. One question > I have for anyone who may have used this module in the past: > Can I find the directory rights AND the directory inheritance > rights, like the RWXD in "SYSTEM (Full)(RWXD)"? The security > hash only provides one ACE (bitmask) per user account, where > there are actually two ACEs for each account. > > -----Original Message----- > From: Shawn Boyle [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 13, 2002 9:32 AM > To: Hornyak, Douglas > Cc: [EMAIL PROTECTED] > Subject: Re: Recursive Win32::Perms memory leak > > > Douglas, > > I don't really have an answer for you except to say that I > had the same > problem. My script was running through all of the directories > on a server and > getting rights information. One of the servers had over > 90,000 directories and > 2GB of RAM and the script would use up all of the available > memory before it > even came close to finishing. I couldn't install Perl on the > server so I had to > use ActiveState's perlapp to create an exe. I thought it > might be perlapp > becuase the script seemed to use less memory when I used the > --nocompress > switch, but I was never able to install Perl on that server > to do a true test. > > I did the same thing you did: I commented out different parts > of the script > until I found the one that was leaking all of the mem, and I > came up with the > same results -- but this was all using perlapp. I wound up > writing another > script that would call my main script on different parts of > the server, and > then combine all of the results. > > -Shawn > > ---- Original message ---- > >Date: Thu, 13 Jun 2002 09:02:28 -0400 > >From: [EMAIL PROTECTED] > >Subject: Recursive Win32::Perms memory leak > >To: <[EMAIL PROTECTED]> > > > >I have been struggling with a recursive ACL collection > program for some > >time > now. It has been displaying memory leak problems and when > unleashed on a server > with 10's of thousands of folders it runs out of memory. > > > >I desperately searched for solutions, researching my use of hash > >references > and localized variables, etc. to no avail. Mostly I found > thread of people > arguing about perl vs. java and other useless junk. > > > >I tried perl's -d switch but could not get a listing of my variables > >with "V" > or "X variablename" or "V main::processLevel" or anything. I > could always see > just the built-in vars and a couple of others. I was looking > for dangling > anonymous hashes. > > > >So I resorted to the old standby. I created a small perl script to > >emulate the > recursive behavior of the larger script. > > > >First I looped the dir command and watched the memory. Stuck around > >1700 for > the entire script. Good. Second I added hash references to > the localized > variables during the loop. Still only went up to about 2600 > and stayed put. > Hmmm. Third I added a call to Win32::Perms. Bingo! Memory > climbed and climbed, > only stopping when the script finished all directories! For > the test server, it > climbed over 12000 before it finished. I won't even try a > large file system. > > > >So the question is: How do I kill the Perms object? Close() > and undef > >don't do > it? > > > >Here's the script (and attached is a "clean the heck out of > >everything" > version): > > > >########################################################### > >### test recursion using scope alone for cleanup > >### > >use Win32::Perms; > > > >my %r_level = (); > >my $r_level = \%r_level; > > > >$r_level->{var_Path} = "\\\\server\\C\$"; > > > >processLevel( $r_level ); > > > > > >sub processLevel { > > ### a recursive function > > my $level = shift( @_ ); > > my $result = undef; > > > > addHashRef( $level ); > > > > my @dirs = `dir /A:D /B /-C /O:N $level->{var_Path}`; > > > > foreach my $dir ( @dirs ) > > { > > chomp( $dir ); > > > > ### create a hash reference to hold our child data > > my %c_level = (); > > my $c_level = \%c_level; > > > > ### add the var_Path variable to our child level by > concatenation of the parent var_Path > > ### that is, put 'em together... > > $c_level->{var_Path} = $level->{var_Path}."\\".$dir; > > > > addHashRef( $c_level ); > > > > processLevel( $c_level ); > > } > > > >} > > > > > >sub addHashRef{ > > ### this is an immitation of what the getACLs sub does > > ### it uses Win32::Perms to get DACLKS, then adds them as hashes > > my $level = shift( @_ ); > > > > $oPerms = new Win32::Perms( $level->{var_Path} ); > > if ( $oPerms ) > > { > > $oPerms->Close(); > > undef $oPerms; > > } > > > > ### manually add junk just for testing > > $level->{var_DACL}->{var_File}->{S-1-1-01} = 1; > > $level->{var_DACL}->{var_File}->{S-1-1-02} = 1; > > $level->{var_DACL}->{var_File}->{S-1-1-03} = 1; > > $level->{var_DACL}->{var_File}->{S-1-1-04} = 1; > > $level->{var_DACL}->{var_File}->{S-1-1-05} = 1; > > > > $level->{var_DACL}->{var_Dir}->{S-1-1-01} = 1; > > $level->{var_DACL}->{var_Dir}->{S-1-1-02} = 1; > > $level->{var_DACL}->{var_Dir}->{S-1-1-03} = 1; > > $level->{var_DACL}->{var_Dir}->{S-1-1-04} = 1; > > > >} > >########################################################### > > > > <<recurse_cleanit.pl>> > > > > > >Doug Hornyak > >CPS, UBSW > >[EMAIL PROTECTED] > > > > > >________________ > >recurse_cleanit.pl 4k bytes > >________________ > > > >Visit our website at http://www.ubswarburg.com > > > >This message contains confidential information and is intended only > >for the individual named. If you are not the named addressee you > >should not disseminate, distribute or copy this e-mail. Please > >notify the sender immediately by e-mail if you have received this > >e-mail by mistake and delete this e-mail from your system. > > > >E-mail transmission cannot be guaranteed to be secure or error-free > >as information could be intercepted, corrupted, lost, destroyed, > >arrive late or incomplete, or contain viruses. The sender therefore > >does not accept liability for any errors or omissions in the > contents > >of this message which arise as a result of e-mail transmission. If > >verification is required please request a hard-copy version. This > >message is provided for informational purposes and should not be > >construed as a solicitation or offer to buy or sell any > securities or > >related financial instruments. > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > _______________________________________________ > Perl-Win32-Admin mailing list > [EMAIL PROTECTED] > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > _______________________________________________ > Perl-Win32-Admin mailing list > [EMAIL PROTECTED] > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > _______________________________________________ Perl-Win32-Admin mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
