Wed Jan 21 12:09:40 2015: Request 101662 was acted upon.
Transaction: Ticket created by thoke
       Queue: PAR-Packer
     Subject: Prevent shared libs from being cached in memory on AIX
   Broken in: 1.024
    Severity: Important
       Owner: Nobody
  Requestors: th...@northpeak.org
      Status: new
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101662 >


Here's the email thread from the par mailing list:

On AIX, when I execute my pp'd binary (pp -C) the shared libs remain loaded in 
memory. I'd like to prevent that by changing the permissions on the files in 
the cache. If the execute permissions are removed from 'other', then the 
library won't be kept in memory on AIX.

Will this patch be sufficient?  Any issues with it that I'm not considering?  I 
wonder if it could be further restricted to 0700 or even 0500?

$ svn diff par/PAR-Packer/trunk/ par/trunk/
Index: par/PAR-Packer/trunk/myldr/boot.c
===================================================================
--- par/PAR-Packer/trunk/myldr/boot.c   (revision 1533)
+++ par/PAR-Packer/trunk/myldr/boot.c   (working copy)
@@ -66,7 +66,7 @@
     if (close(fd) == -1)
         return EXTRACT_FAIL;
 
-    chmod(*ext_path, 0755);
+    chmod(*ext_path, 0750);
     return EXTRACT_OK;
 }
 
Index: par/trunk/lib/PAR/Heavy.pm
===================================================================
--- par/trunk/lib/PAR/Heavy.pm  (revision 1533)
+++ par/trunk/lib/PAR/Heavy.pm  (working copy)
@@ -158,7 +158,7 @@
         binmode($fh);
         $member->extractToFileHandle($fh);
         close $fh;
-        chmod 0755, $filename;
+        chmod 0750, $filename;
     }
 
     return $filename;


If that's all sufficient, how should I proceed? Get commit permission?  Submit 
an RT against PAR and PAR-Packer?

Thanks
-Tim

---
What do you mean by "remain loaded in memory" - even after the process created 
by executing the pp'd binary has exited?
And why would changing the "other" bits on the files have any effect on that?
 
Cheers, Roderich
 
---

Yes, you've got it.  They remain loaded in memory even after the pp'd binary 
has exited and been cleaned up (cache removed).  The result is that when the 
pp'd binary is called again (and again, and again), another copy get's loaded 
(and kept) in memory because it's in a different cache directory.  The 
workaround is to run slibclean, but by changing the "other" bits, AIX doesn't 
bother trying to keep it in shared memory.

Thanks
-Tim

---

I see, weird.
Your patch looks reasonable, shouldn't break in other environments as cache 
files should be in a per-user tree anyway.
Just a file bug on RT against PAR-Packer (because that's were I look first), 
the text of your original post should do.
 
Cheers, Roderick

Reply via email to