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: [email protected]
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