[Python-Dev] BSDDB3

[Trent Nelson]

Hi Jesus,

> Martin v. Löwis wrote:
> | I think it would be helpful if you could analyze the crashes that
> | bsddb caused on Windows. Just go back a few revisions in the
> | subversion tree to reproduce the crashes.
>
> I have no MS Windows machines in my environment :-(

I remember those rampant BSDDB crashes on Windows well.  I brought this up with Martin at PyCon; I really don't think we can fault BSDDB here -- basically, the tests weren't cleaning up their environment in the right order, so BSDDB was getting passed completely and utterly bogus values.  I *think* I managed to persuade Martin that this was indeed our fault, and we can't really hold BSDDB accountable.  (My argument being that if a 3rd party app says the behaviour of a method is undefined if you pass it a null pointer, and you pass it a null pointer, and it crashes your program, it's your fault, not theirs.)

Once this was addressed, the BSDDB tests ran more or less on Windows 32-bit without error.  Windows x64 was another matter though -- I traced the problem down to wildly conflicting compiler and linker flags between our Python build and how we were building BSDDB (or rather how BSDDB builds out of the box on Windows).

My solution was to drop our reliance on the Berkeley_DB.sln/db_static.vcproj files completely, and mimic a bsddb44 vcproj in our own pcbuild.sln, which basically meant all the BSDDB source code got built in the exact same fashion as the rest of Python.  I also took this approach with sqlite3 and it's worked really well -- there have been no issues with either module since this change.

I've also got bsddb45.vcproj and bsddb46.vcproj projects floating around in one of my local branches somewhere.  These mimic the corresponding BSDDB projects, with the intent being that when it comes to release time for 2.6 and 3.0, we'd make a decision about which one to ship with, and then set the Python _bsddb module to use that.  I should probably pick that up again...

Hope this clarifies things...

Regards,

        Trent.