[Date Prev][Date Next]
Re: Solaris dlapd core dumps - more clues
In article <3640DBD2.999639EE@tipper.oit.unc.edu>,
Simon Spero <email@example.com> wrote:
>Content-Type: text/plain; charset=us-ascii
>I've been poking around into some of the solaris issues,I now have a
>way to reliably make slapd dump core or lock up so I've hooked her up to
>purify and started poking around. There seem to be some interesting
>problems with freeing memory in the cache whilst it's still in use: a
>representative chunk follows at the end of the message.
>I can trigger the bug by deleting records; these records have already
>been pulled in as part of a previous search. The bug did not manifest
>itself when the field the search was performed on was not indexed; when
>the field is indexed the free frobbing begins in earnest.
>There are a lot of FMR errors reported, but they all seem to be
>spin-offs of the same root cause, so I'm only including one set of
>messages. I'm not real familar with the ldbm back end code, so I'm
>hoping someone who is will be able to look at the trace and go "duh".
> FMR: Free memory read (219702 times)
> This is occurring while in thread 17:
> cache_entrydn_cmp [cache.c:34]
> static int
> cache_entrydn_cmp( Entry *e1, Entry *e2 )
> => return( strcasecmp( e1->e_dn, e2->e_dn ) );
This sure looks like what I was trying to fix with the reader/writer
locks for entries...
I had thought that the avl_*() routines where only looking at things
that did not need to have a reader/writer lock before accessing.
But it looks from the above that e_dn for example may need to be
This presents some problems... I don't know if we want to try and
add a reader lock/unlock to each of the comparisons as we walk through
I'll have to think about it for a bit. Any other suggestions would be welcome...
Stuart Lynne <firstname.lastname@example.org> 604-461-7532 <http://www.fireplug.net>
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 88 EC A3 EE 2D 1C 15 68