| Paul Colquhoun 2005-05-12, 7:55 am |
| On Thu, 12 May 2005 04:30:31 GMT, Scott Lurndal <scott@slp53.sl.home> wrote:
| Izo <I@siol.net> writes:
|>Kernel 2.4.x, 2.6.x
|>
|
|>The behaviour seems slightly confusing for me. Why ? The file system /
|>kernel allows the shared object rewrite / replace without complaint and
|>it harms the program run-time behaviour while it blocks the program's
|>binary replacement while such action (in contrary to shared object
|>replacement) does not harm the program's operation.
|>
|>What is the reason for such behaviour (program crash etc.) anyway ?
|
| When the kernel pages out a code page, it just discards it, since it
| can always reload it directly from the object itself (e.g. executable
| or shared object). So, while some of the code pages will be
| in memory when you overwrite the .so, not all will be. When the next
| code page is paged in from the new shared object, the function calls
| from the old code pages will call incorrect addresses in the new
| code pages and will cause arbitrary random code to be executed which
| will quickly cause a system fault.
Unfortunatly it doeszn't work quite that way. When the library is opened,
it gets a file handle attached. This file handle acts just like a directory
entry. The file will not be deleted from the disk until all directory entries
and file handles are removed/closed.
When the library is updated, the new library gets its own disk blocks, and
a new directory entry, but the old library is still on disk and the file
handle pointer to it is still valid.
When the OS needs to page in from teh library, it uses the file handle
it already has, not the (new) directory entry.
--
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/~paulcol
Asking for technical help in newsgroups? Read this first:
http://catb.org/~esr/faqs/smart-questions.html#intro
|