Heap corruption after integrating into app that uses sqlite3

[myersa]

Hello,

I am experiencing heap corruption after integrating wxWebConnect into a C++ application that was already using Sqlite3.

Details:
My application uses the open-source distribution of Sqlite3 version 3.7.3, built on my development machine (Windows XP 32-bit, X86 processor) as a DLL with default settings (including using the Unicode character set). The application itself does not use Unicode (character set = "Not Set").

I modified wxWebConnect 1.1 to build as a DLL, and use wxWidgets DLLs instead of static libraries (because our application already used wxWidgets DLLs). I built wxWebConnect with character set = "Not Set".

I noticed that the XUL runner uses Sqlite3 DLL version 3.6.16, and the Sqlite DLL was built to use Unicode.

Here is the issue: on my first call to sqlite3_close() after initializing the XUL runner, I get a heap corruption warning saying:

"""
HEAP[app.exe]: HEAP: Free Heap block 27dd000 modified at 27dd494 after it was freed
Windows has triggered a breakpoint in app.exe.

This may be due to a corruption of the heap, and indicates a bug in app.exe or any of the DLLs it has loaded.
"""

This occurs when using the Release DLL of Sqlite 3.7.3. Using the Debug DLL results in this warning, as well as tremendous memory leaks when the application unloads.

In the "Output" window of Visual Studio, I can see MY copy of Sqlite3.dll being loaded when the app starts up (statically), then I see XUL loading its own copy of sqlite3.dll when it gets initialized (I think it's loaded dynamically, but can't be sure). I can avoid the double-loading of sqlite3.dll by modifying my PATH environment variable and deleting XUL's copy of sqlite3.dll, forcing XUL to use the copy of sqlite3.dll that's already loaded, however this does not appear to make any difference.

When using the Sqlite Release DLL, it seems that the warning can be ignored and there are no harmful consequences, so I have pressed on with the integration and put this issue aside for the time being. Nevertheless, these kinds of issues make me and my teammates quite nervous, and we would really like to resolve the problem completely. If anyone can shed some light on potential causes or (especially) solutions, it would be much appreciated.

Thanks

[myersa]

I retrieved and built XULrunner 1.9.0.11 from "http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.0.11/source/", and replacing the contents of the "xr" folder with the output of this build solved the problem. There's still a memory leak at application shut down if I use the Debug DLL of SQLite, but switching to the release DLL solves this as well, and in any case I was more concerned about the heap corruption.

One notable difference between my build of 1.9.0.11 and the version that was distributed with wxWebConnect was, when I opened each xulrunner.exe using DependencyWalker, I found that the wxWebConnect version had a link to sqlite3.dll with a link checksum of 0, while my version linked to sqlite3.dll with a link checksum that matched the file checksum.

[myersa]

I discovered that downloading a pre-built version of XUL runner is actually the best solution, as building and packaging it from source is a huge chore (particularly on Windows).

Just make sure that the sqlite3.dll link checksum is non-zero and matches the actual checksum (use Dependency Walker on xulrunner.exe).