I have never seen this issue before, but here is what is happening. I link an executable against two dynamic mlib libraries veclib and lapack. We place a newer version of these libraries in a write only directory and point the shlib_path at that directory. When the executable runs, it gets a page I/O modification error. The odd thing is we tracked it down to the executable modifying the two shared libraries. If the directory is writable the executable succeeds and the modification times on the shared libraries change. I don't have any idea why an executable would do anything to change a shared library at runtime or fail when it can't. Does anyone have any idea why this would occur. Is it that it is not the same library linked against. I didn't think this mattered for shared libraries as long as the calling convention is the same. So I am looking to try and figure out what weird behind the scenes thing is going on here. Thanks for any insight.

I would question what odd thing dld has been asked to do.... it sounds like running code is attempting to write read-only memory.

what does the output of ldd show for one of the libraries?

I have already done an ldd and chatr, it depends on the libraries, the code hasn't changed in a long time, just a different setup it is being linked in. So are there any other thoughts out there?

---------- Post updated 08-08-09 at 08:11 AM ---------- Previous update was 08-07-09 at 07:06 PM ----------

Just wanted to see if anyone new out there had any thoughts on this issue.

I have tracked this issue to being something about memory locking over NFS. As soon as the process goes to mlockall, we update the modification time on the shared library. And if the shared library is read only, we get a Page I/O modification error. If I put the libraries local to the machine, it doesn't happen. So it seems to be some sort of NFS conflict. Has anyone seen this type of thing before?

---------- Post updated at 05:51 PM ---------- Previous update was at 06:35 AM ----------

found I was able to reproduce the symptom with just a hello world type of app.
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

void main()
{
mlockall(CTL_CURRENT)
printf("hello world\n");
}

linked by the following
cc hello_world.c -o hello_world -L/opt/mlib/lib/pa2.0 -lveclib -llapack -Wl,s+

our home directories are NFS mounted so if I copy pa2.0 to /home/mine/pa2.0 and check the timestamp then
change my SHLIB_PATH EV to point to /home/mine/pa2.0
the timestamps change from the original copy after I run hello_world.