77 lines
2.9 KiB
Plaintext
77 lines
2.9 KiB
Plaintext
From: pduffin at mailserver.hursley.ibm.com (Paul Duffin)
|
|
Date: Wed, 28 Apr 1999 11:07:21 +0100
|
|
Subject: WARNING: AIX and dynamic loading.
|
|
References: <7g4i77$qif$1@nnrp1.dejanews.com>
|
|
Message-ID: <3726DDD9.19A1@mailserver.hursley.ibm.com>
|
|
Content-Length: 2644
|
|
X-UID: 251
|
|
|
|
Jakob Schiotz wrote:
|
|
>
|
|
> Hi everybody,
|
|
>
|
|
> I would like to warn developers using AIX against this trap waiting
|
|
> for us to fall into. (I am cross-posting this to the SWIG mailing list
|
|
> although it is not strictly a SWIG problems, as SWIG users will be
|
|
> doing just the kind of stuff that gets you into trouble).
|
|
>
|
|
> SCENARIO:
|
|
> You are developing a dynamically loaded C module for Python (or
|
|
> possibly for other languages). You place the module in a directory on
|
|
> the PYTHONPATH. That directory is NFS mounted. Or you are loading
|
|
> the module directly from the directory where you compiled it, and that
|
|
> directory is NFS mounted.
|
|
>
|
|
> SYMPTOMS:
|
|
> You are improving the code, but it does not seem to have any effect at
|
|
> all. Eventually you realise that Python is loading the buggy version
|
|
> of your module that you tried out this morning, although _all_ copies
|
|
> on disk are the new improved version you just wrote !
|
|
>
|
|
> PROBLEM:
|
|
> If you copy the module to the PYTHONPATH directory using cp, the old
|
|
> file gets overwritten, but keeps the same inode number. Apparently,
|
|
> the AIX dynamical loader is caching the module somewhere, and does not
|
|
> discover that the file has been modified. (If the directory is not NFS
|
|
> mounted cp will fail with an error message saying that you cannot
|
|
> overwrite a running program - although the program has stopped.)
|
|
>
|
|
> It is _possible_ that this only occurs if the module you wrote causes
|
|
> python to dump core. It certainly makes it frustrating to fix the
|
|
> bug as you continue to get the version that dumps core loaded into
|
|
> python, even after you fixed the bug.
|
|
>
|
|
|
|
I found this problem when developing extensions for Tcl, my solution
|
|
was to run slibclean (as root) which removes all unused modules from the
|
|
system.
|
|
|
|
> SOLUTION:
|
|
> You makefile should remove the old module (the .so file) before copying the
|
|
> new version into the installation directory. Then the file gets a new
|
|
> inode number and the loader discovers that it has been changed. If
|
|
> you ever load the module directly from the development directory you
|
|
> should also remove the .so file before compiling/linking, as you will
|
|
> otherwise get hit by the same bug.
|
|
>
|
|
|
|
That is very useful, as I had a solution I did not bother to find out
|
|
what was happening.
|
|
|
|
> I just wanted to warn you all about this bug in AIX. I wasted too much time
|
|
> on this last Friday :-(
|
|
>
|
|
|
|
AIX should definitely look at the modification date as well as the
|
|
inode.
|
|
|
|
--
|
|
Paul Duffin
|
|
DT/6000 Development Email: pduffin at hursley.ibm.com
|
|
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
|
|
Internal: 7-246880 International: +44 1962-816880
|
|
|
|
|
|
|
|
|