Corrupt winbindd_idmap.tdb file (Was: Am I going mad or does TDB allow multiple writers to update the freelist?)

[Richard Sharpe]

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.

-- 
Regards,
Richard Sharpe