On Wed, 13 Mar 2013, Juergen.Sprenger@swisscom.com wrote: Well...
# adb /usr/local/libexec/slapd core.slapd.220 core file = core.slapd.220 -- program ``/usr/local/libexec/slapd'' on platform SUNW,SPARC-Enterprise-T5120 SIGABRT: Abort
Obviously you're generating core, but it's not a SEGV; rather...
libc.so.1`abort+0x110(b07ff4e8, 1, fed833f0, ffba0, fed85518, 0) libc.so.1`_assert+0x64(12d0d0, 12c9d0, 3a8, 0, ff8bc, 19418c) connection_next+0x138(0, b07ff7c4, b07ff7c0, 199d1c, fd17ba00, 1a2000)
slapd is "voluntarily" assert()'ing something. In OpenLDAP software, these assertions include __FILE__, __LINE__ which are a really helpful clue (and don't contain passwords/other sensitive information). Perhaps you could track that down as a starting point?
I might suggest you consider using a more symbolic debugger like dbx/gdb; I think people will be more familiar with those than adb/mdb when helping you on non-Solaris-specific lists. If you're good enough with adb to coerce that output, feel free to continue, but the readily documented debugging suggestions (e.g. those in the OpenLDAP FAQ) are not geared for adb/mdb.
(Dangerously/prematurely) dusting off the crystal ball...
data model = _ILP32 flags = MSACCT|MSFORK
A T5120 is a pretty large machine to be running a 32-bit build on. You may well be running into some address-space related limit, and you may see this when you find your assert() string. I'd highly suggest recompiling/reloading your database with 64-bit binaries. There's no reason to buy a modern server and use only a fraction of its capacity.