开发者

Possible Shared Library conflict causing corrupted SQLite database

开发者 https://www.devze.com 2023-02-05 01:00 出处:网络
Our app is a browser plugin for FF & Chrome. The app uses SQLite to store data. The SQLite files are getting corrupted on FF/Linux or FF/Mac.

Our app is a browser plugin for FF & Chrome. The app uses SQLite to store data. The SQLite files are getting corrupted on FF/Linux or FF/Mac.

Our hypothesis for the files etting corrupted is described below:

1) FF is loading SQLite 3.7.1 as a shared library

2) Our plugin (which is a shared library) is statically linked against SQLite 3.7.4. We have made sure that our plugin is exporting only one symbol NSGetModule (required by FF to load a plugin). All other symbols are hidden using --version-script compiler option

3) Something bad is happening because of possible symbols conflicts across multiple versions of SQLite library

Additional comments:

1) The same problem does not arise in Chrome as Chrome runs plugin in separate processes

2) We are not facing this issue on Windows. Only on Linux or Mac

3) We have to use SQLite 3.7.4 as we are using the features of the latest version

开发者_开发知识库

Any ideas?


Your guess of the cause -- unexpected symbol conflict -- is quite likely correct.

If you have correctly hidden everything (as you say you did), then output from

nm -D your-plugin.so

on Linux should list only the NSGetModule as defined, and no SQLite symbols at all (I expect you'll still see quite a lot of unresolved symbols from libc, and whatever else you link your plugin against).

You can run Firefox on Linux with LD_DEBUG=symbols,bindings. That will produce many MBytes of output, but you should see very few references to your plugin, none for any SQLite symbols.

Is that what you in fact observe?

0

精彩评论

暂无评论...
验证码 换一张
取 消