|
| Well, I have been googling a while and have found this thread
(https://www.redhat.com/archives/fed...r/msg04466.html)
in redhat archives dealing with the matter. Can just somebody be kind
and prove the thread content being correct or is there maybe some other
explanation/solution to this problem ?
Izo
Izo wrote:
> Kernel 2.4.x, 2.6.x
>
> First of all, looking from the point of correct binary distribution
> manner, the situation I want to describe is not quite valid. I am aware
> of that, still, I want to know the reason for the system behaviour
> caused by such situation.
>
> Let's suppose the running program P uses the shared object S.so.C.A.R.
> During development, of course, the shared object is changed, many times
> not only the implementation but also function prototypes are added or
> changed while the version numbers (C.A.R) remain unchanged. Many times,
> during tests, the shared object happens to be replaced with new one when
> the program (that uses it) runs. What happens is that the program most
> probably crashes, at least it always does at first try to call the
> function from replaced shared object.
>
> 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 ?
>
> Izo
|
|