Paul B. Henson wrote:
I was interested in using openldap under OpenBSD; they currently have mdb disabled as they say it is broken. That OS lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but supposedly theoretically it should work with that. I tried running the mdb tests, and it immediately segfaults:
Program terminated with signal 11, Segmentation fault.
2773 flags |= env->me_flags & MDB_WRITEMAP;
It looks like mdb_txn_begin is being passed a NULL env? I haven't started poking around yet to see why that might be, but I thought I'd just toss this out there in case an expert had a thought before I spent a lot of time on it :). Thanks...
OpenBSD's lack of a unified buffer cache is a pretty glaring deficiency, yes. Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it.
For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least.
On Thu, Aug 03, 2017 at 09:46:20PM +0100, Howard Chu wrote:
Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it.
It's not my first choice for an enterprise ldap deployment, but I do like it for certain network functions, and in this case I wanted to run a mirrored openldap deployment on two redundant openbsd routers as a password backend for radius and smtp auth...
For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least.
2.4.44 is what's currently in their ports tree with some patches to work (barring mdb), so I was starting lazy :). I'll move up to current code, it will just require porting their local OS mods to the latest version.
From my initial look, mdb_env_create() successfully sets mdb->mi_dbenv,
it's still valid in mdb_db_open(), but by the time it reaches be->be_entry_put in slapadd() it's NULL :(. I'll keep tracing it, thanks.
On Thu, Aug 03, 2017 at 02:20:29PM -0700, Paul B. Henson wrote:
From my initial look, mdb_env_create() successfully sets mdb->mi_dbenv, it's still valid in mdb_db_open(), but by the time it reaches be->be_entry_put in slapadd() it's NULL :(.
It turned out it was only sometimes NULL. The culprit was actually the local OpenBSD patch that was added to mdb_db_open() to ensure MDB_WRITEMAP is always set:
if ( !(flags & MDB_WRITEMAP) ) { Debug( LDAP_DEBUG_ANY, LDAP_XSTRING(mdb_db_open) ": database "%s" does not have writemap. " "This is required on systems without unified buffer cache.\n", be->be_suffix[0].bv_val, rc, 0 ); goto fail; }
There were two problems with it; first, it accesses the local flags variable before it is initialized to mdb->mi_dbenv_flags shortly thereafter, so the value is random and the if block nondeterministically triggers, and second, it doesn't assign a failure value to rc before it jumps to fail:, so the function returns successfully but with a closed be.
mdb has been disabled for a while, so I'm guessing the first issue might have occurred over time as backend.c changed and the patch was just blindly updated without testing. The second issue I'm not sure about.
I temporarily tweaked it to always enable MDB_WRITEMAP so I could run the mdb test suite (which doesn't have it enabled for everything) and so far it seems to be working.
I would hope that this simple issue isn't why they've had it disabled all this time, but I guess I'll see what happens with the full test suite as it progresses.
openldap-technical@openldap.org
-
Howard Chu -
Paul B. Henson