Corrupt winbindd_idmap.tdb file (Was: Am I going mad or does
TDB allow multiple writers to update the freelist?)
realrichardsharpe at gmail.com
Tue Jan 20 23:58:34 GMT 2009
On 1/20/09, Richard Sharpe <realrichardsharpe at gmail.com> wrote:
> On 1/20/09, Richard Sharpe <realrichardsharpe at gmail.com> wrote:
> > On 1/20/09, Volker Lendecke <Volker.Lendecke at sernet.de> wrote:
> > > On Tue, Jan 20, 2009 at 02:29:25PM -0800, Richard Sharpe wrote:
> > > > OK, now I understand, I think. I assumed that the tdb control
> > > > structure was part of the mmaped memory and that they were both
> > > > looking at the same memory.
> > > >
> > > > Hmmm, have to look harder for the tdb freelist corruption I have found, then.
> > >
> > >
> > > You're certain that none of the smbds on that box has ever
> > > crashed? This might leave the tdb also in a corrupt state.
> > winbindd_idmap.tdb ...
> > I dont think so, but will check, I need to check into that. There is
> > one report of a loop in the freelist, and I have an example of a
> > corruption in the freelist that looks really weird.
> > The next pointer for the penultimate entry on the free list points 536
> > bytes beyond the start of the unallocated area and what should be the
> > last entry on the free list.
> > It has the feel of multiple processes messing with the freelist at the
> > same time.
> One of the hash chain hearders points into what is the unallocated
> region and one of the hash chains has an entry with a .next that
> points also to the unallocated region.
> I guess that there could have been as system crash where some stuff
> made it to the file and some stuff failed to make it to the file.
OK, that looks more like the issue. I think the correct approach would
be to convert the code to use TDB's transactional facilities to
prevent situations like this.
More information about the samba-technical