[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antwort: Re: (ITS#4848) Another slapd startup segfault

Michael.Heep@o2.com wrote:
> Hello Pierangelo,
>> ando@sys-net.it wrote:
>> The above had nothing to do with your problem.  Your problem is related
>> to the fact that you intermixed overlay and database configuration
>> statements, so the idletimeout statement after the accesslog overlay
>> instantiation was causing invalid memory write (beyond the private data
>> of the accesslog overlay instead of in the private data of the bdb
>> database) resulting in heap corruption.
> You meant the limits option, not the idletimeout, right? Because when I 
> remove it slapd starts and runs properly.
> But now I'm quite lost here. With that statement I intended to disable the 
> default limits for all users below ou=CNO-LDC when viewing the accesslog 
> (as it's bound to grow beyond the 500 entries sooner or later). The 
> manpage lists limits as a general database option, so I assumed placing it 
> at the end of the accesslog db options would impose these limits on it. 
> Now where would be the proper placement to achive that?
> Under 2.3.33 in my test environment with an accesslog > 500 entries and 
> the limits directive at just this place in the conf everything worked as 
> expected.

The limits was just a false track.  It was idlcachesize to trigger the
dangling memory access, but the root cause is the config statement
ordering which triggered something much more subtle: basically, if
database statements follow overlay instantiation, slapd is fooled into
writing to the database (in this case back-bdb) private structure using
a pointer to the overlay's (in this case accesslog) structure.  This is
now fixed in HEAD (thanks to Howard), but backporting to re23 may not be
trivial, so please stick with strict ordering of configure statements.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it