如果在使用 dlopen() 显式加载共享库后删除/替换共享库，会发生什么？

Question

如果在使用 dlopen() 显式加载共享库后删除/替换共享库，会发生什么？

dlopen() 是否将整个共享库加载到内存中？ 或者从长远来看，dlopen() 必须不时引用驻留在文件系统中的先前加载的库。 如果是这样，我如何强制 dlopen() 将整个 .so 加载到内存中？

标志 RTLD_NOW 是否意味着将整个库加载到内存中？

Answer 1

如果在使用 dlopen() 显式加载共享库后删除/替换共享库，会发生什么？

如果您删除然后写入一个具有相同名称的新文件，则不会发生任何不好的事情。 但是如果您覆盖现有文件，您可能会看到奇怪的崩溃。

dlopen() 是否将整个共享库加载到内存中？

不，它只是将它mmap到内存中。 除非您对库的代码和数据使用mlock ，否则它将从磁盘按需分页。

标志RTLD_NOW是否意味着将整个库加载到内存中？

一点也不。 RTLD_NOW与您的问题无关，也无济于事。

---

那么，为什么会有之间的差异unlink + write与write在现有的数据？

在 UNIX 上删除（通过unlink系统调用）一个文件实际上并没有从磁盘中删除它——数据保留在磁盘上，直到对文件的所有引用都消失了。 一个打开的文件描述符构成了这样的引用，现有的mmap也是如此。

但是如果你覆盖已经被mmap ed 的现有文件，请求分页可能会从磁盘带来新的内容，可能会带来灾难性的结果。

PS 正如 o11c 所指出的，覆盖mmap ed 的文件可能会因ETXTBUSY而失败，尽管这取决于操作系统和文件系统。