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

Re: Solaris slapd core dumps - more clues

I don't think it's a threading problem, since there's only a single
thread active during the test case. I guess the next step is to try
shrinking the database till it's small enough to step through.

fun fun fun :-)


On 6 Nov 1998, Stuart Lynne wrote:

> In article <3640DBD2.999639EE@tipper.oit.unc.edu>,
> Simon Spero <ses@tipper.oit.unc.edu> wrote:
> >--------------3504F5EEB82D3B9F3DBBB7F6
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >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".
> >
> >Simon
> >
> >      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 
> protected.
> 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
> the tree.
> I'll have to think about it for a bit. Any other suggestions would be welcome...
> -- 
> Stuart Lynne <sl@fireplug.net>      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

Now available - The Freddy Hayek Kayak            | "Pass me another elf
Paddle Your Own Canoe! Be Rowed To Surfdom!       | Sergeant- this one's
>From The Taco Institute for Dyslexic Libertarians | split"
  Moments ago I had everything. Now, there's a cow in my nose - La Salla