可能的共享库冲突导致 SQLite 数据库损坏答案

【问题标题】：Possible Shared Library conflict causing corrupted SQLite database可能的共享库冲突导致 SQLite 数据库损坏
【发布时间】：2011-01-13 14:30:53
【问题描述】：

我们的应用是 FF 和 Chrome 的浏览器插件。该应用程序使用 SQLite 来存储数据。 SQLite 文件在 FF/Linux 或 FF/Mac 上被损坏。

我们对文件损坏的假设如下所述：

1) FF 正在将 SQLite 3.7.1 作为共享库加载

2）我们的插件（这是一个共享库）是静态链接的 SQLite 3.7.4。我们确保我们的插件只导出一个符号 NSGetModule（FF 需要加载插件）。所有其他使用 --version-script 编译器选项隐藏符号

3) 由于可能的符号冲突，正在发生不好的 跨多个版本的 SQLite 库

其他 cmets：

1) Chrome 中不会出现相同的问题，因为 Chrome 在中运行插件单独的进程
2）我们在 Windows 上没有遇到这个问题。仅适用于 Linux 或 Mac
3) 我们必须使用 SQLite 3.7.4，因为我们使用的是最新版本的功能

有什么想法吗？

【问题讨论】：

我只能想到两件事。 1）你的假设是错误的。 2）检查“nm -s”的输出，以确保不仅是您的插件正在导出的内容，还包括它在加载时外部引用的内容，并确认所有 SQLite 符号都已解析。

标签： linux shared-libraries

【解决方案1】：

您对原因的猜测——意外的符号冲突——很可能是正确的。

如果您正确隐藏了所有内容（正如您所说的那样），则输出

nm -D your-plugin.so

在 Linux 上应该只列出定义的 NSGetModule，而根本没有 SQLite 符号（我希望你仍然会看到来自 libc 的很多未解析的符号，以及你链接插件所针对的任何其他符号)。

您可以使用LD_DEBUG=symbols,bindings 在 Linux 上运行 Firefox。这将产生许多 MBytes 的输出，但您应该看到对您的插件的引用很少，任何 SQLite 符号都没有。

这是你事实上观察到的吗？

【讨论】：